-
Notifications
You must be signed in to change notification settings - Fork 249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
blocks placed at incorrect position or time #3372
Comments
From IRC:
I have also failed to find a commit when this bug was introduced. Either it's been there "mostly from the beginning", or it's in some dependency that I fail to recompile/pull the old version for. I gave up trying to make versions older than 8b19a94 build, but as far as I can tell the bug is already present there. Note that I had to
at some point to keep the build working in a debian:stable docker container due to the |
Can you reproduce the bug with the |
|
issue 1: close key frame insertion and reservoir-frame-delayPlaying around a bit, I suspect this is a rate control issue that occurs when rav1e inserts a key frame early (before max keyframe interval) and Let's look at some graphs. Here's with rav1e's default settings (i.e. These metrics have been grabbed from Lines 890 to 897 in c7c72b5
Lines 1227 to 1228 in c7c72b5
The x-axis are whenever the code-path in question got called, so roughly matches video progress. y-axis are either bits for the top two graphs, or trans form units for the bottom one. We can see that The interesting bit seems to be the The dip in Increasing Trying out different variants where the "reservoir isn't startled by surprise key frame" yield similar results - low quality, but not completely distorted. E.g.
Looking at the comment https://github.com/xiph/rav1e/blob/master/src/rate.rs#L589-L596 specifically: "but long enough to allow looking into the next GOP (avoiding the case where the last frames before an I-frame get starved)". It seems that with So we need issue 2: all bits spent earlyAdjusting For single pass, the The general idea is along the lines of // magic value! higher = conserve more bits early on
let penalize_early_strength = 0.25;
let max = self.reservoir_frame_delay as f32;
let min = if ctx.config.max_key_frame_interval == 0 {
0.0
} else {
max - ctx.config.max_key_frame_interval as f32
};
// 0.0 = next KF is far; 1.0 = next KF imminent
let next_keyframe_ratio = (reservoir_frames as f32 - min) / (max - min);
let conservative_rtu = reservoir_tus as f32
* (1.0 - penalize_early_strength * next_keyframe_ratio);
// and then use conservative_rtu instead of reservoir_tus for total_rate this graph shows the difference of old vs proposed approach with tuningObviously these changes affect both quality and size. I tested them with some of my videos, and that's where the magic values come from. But my corpus isn't very diverse, I have checked only a few conditions/scenarios, nor would I rate my eyeballs as "trustworthy and objective measure". Additionally, I'm definitely lacking understanding of the surrounding code and video encoding in general, so it's hard for me to come up with a sensible test strategy. Put differently, if my changes are good or not, I have no clue. Point out flaws in my line of reasoning, please. Should I polish these proposed changes into PRs? Recap
Related
|
Your analysis seems correct for all I could see, but I'd defer to @barrbrain for informed opinions :) |
Describe the bug
![mpv-shot0001](https://private-user-images.githubusercontent.com/307954/318674797-dd208e80-3bf7-40aa-9de1-8aa9c2725c2a.jpg?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQ1NzE2ODksIm5iZiI6MTcyNDU3MTM4OSwicGF0aCI6Ii8zMDc5NTQvMzE4Njc0Nzk3LWRkMjA4ZTgwLTNiZjctNDBhYS05ZGUxLThhYTljMjcyNWMyYS5qcGc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODI1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgyNVQwNzM2MjlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1hODAzMWM1ODY1MWFlMjA0Yjg4MzE0NWQ3ZjZiMmI1NjAxZWYxNTBiMmI3ZmY4YTljZTAzZGFhYTgwYTg5OTAyJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.-7g9VFX7s43VdnMxZAsQAKyR2km-XowHgWYade5Azng)
When I am encoding https://www.breunig.xyz/share/2024-04-02/raw9.yuv (150 MB), at around the 12 second mark rav1e produces distorted blocks like so:
When watching the encoded video, it seems as if the video jumps backwards/forwards by a couple of frames, creating a jarring motion. Put differently, this doesn't appear to be just low bitrate "needs more jpeg" effect. I have uploaded a broken example encode here:
https://www.breunig.xyz/share/2024-04-02/70.ivf
From my testing, it appears that rav1e runs into rate control issues at the affected frames. Changing parameters slightly makes the "jarring motion bug" go away, but the "extremely low bitrate" issue stays. For example, if I set
--skip 200
the motion looks fine, but it retains the short section of more-than-expected jpeg artifacts:https://www.breunig.xyz/share/2024-04-02/72.ivf
FWIW, this is not the only video I have observed the issue with, but I haven't done the work to trim down the reproducer there. However, the general video content is the same: coming from a dark area that is relatively static (i.e. the elevator moving up) to a bright area (i.e. outside) with lots of motion ("zoom-in" as I go forward + left/right pans due to making turns).
I haven't tested all combinations, but see below for the ones I have with a reasonably short input video.
To Reproduce
Expected behavior
Required Information
For the custom built version:
Operating system (for the detailed tests shown above):
The text was updated successfully, but these errors were encountered: