Skip to content
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

[v4] Consider adding prediction to inter mode #170

Open
dwbuiten opened this issue Sep 27, 2019 · 5 comments
Open

[v4] Consider adding prediction to inter mode #170

dwbuiten opened this issue Sep 27, 2019 · 5 comments
Labels

Comments

@dwbuiten
Copy link
Contributor

There's already a dependency on a large part of the previous frame's decoding process for inter frames, and some very simple inter prediction would allow for good compression efficiency gains without a huge hit in performance.

I didn't see this discussed anywhere else, so apologies if it's a duplicate.

@richardpl
Copy link

This is duplicate, there even was GSoC to do just this.

@dwbuiten
Copy link
Contributor Author

Where can I find an open issue for this? A GSoC wiki page for a project that never came to fruition isn't the same thing.

@michaelni michaelni added the v4 label Feb 28, 2023
@Artoria2e5
Copy link

Artoria2e5 commented Feb 18, 2024

@pjotrek-b's http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/ seems to give some intuition on how the current "pseudo-inter" prediction is working:

  1. it works better the smaller the slices you feed it are. 30 slices work better than 4, SD divided into 30 works better than HD divided in 30
  2. twopass often but not always abolishes the size benefit

I guess that just shows the current thing isn't enough for bigger frames. Which we kind of know already, oops.

(My understanding of the two tables is that GOP size set compares GOP=1 vs 300, raw size set compares raw vs GOP=1. I hope I am reading them right.)

(Also there's no raw vs GOP=300 comparison and I am too lazy to do calculations. So I also don't know whether GOP usefully compensates for the compression loss from more slices.)

@pjotrek-b
Copy link

@Artoria2e5: Indeed, there are 2 different comparison tables listed:

  • GOP difference = Filesize difference between GOP=1 and GOP=300.
  • Size difference = Filesize difference between raw (=uncompressed) and GOP=1.

Each with different encoding parameters.

As far as I remember, the 2-pass encoding for abolishes the size benefit in favor of GOP=1, in my tests.
So doing a "2-pass GOP=1" encoding results in similar (smaller) sizes, comparable to GOP=300.

However, the samples used in those tables are very short - and I remember the last time I've tested 2-pass with FFV1, it definitely had issues with regular/longer samples. The 2-pass logfile also became very big very fast.
Therefore, I've actually dropped 2-pass encodings from my consideration radar.

It would actually also be interesting, if these numbers are still valid.
The tests were made in December 2012 - for development of FFV1.3.

@Artoria2e5
Copy link

Artoria2e5 commented Feb 24, 2024

So on the GSoC front, I dug these links up:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants