FFV1 icon indicating copy to clipboard operation
FFV1 copied to clipboard

[v4] Consider adding prediction to inter mode

Open dwbuiten opened this issue 4 years ago • 5 comments

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.

dwbuiten avatar Sep 27 '19 13:09 dwbuiten

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

richardpl avatar Sep 27 '19 13:09 richardpl

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.

dwbuiten avatar Sep 27 '19 13:09 dwbuiten

@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.)

Artoria2e5 avatar Feb 18 '24 04:02 Artoria2e5

@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.

pjotrek-b avatar Feb 21 '24 19:02 pjotrek-b

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

  • Task: https://summerofcode.withgoogle.com/archive/2016/projects/5391653909037056
  • Yingming Fan, Patch 2015-04-23 https://ffmpeg.org/pipermail/ffmpeg-devel/2015-April/172316.html (simple frame-on-frame difference, look like)
  • Станислав Долганов (Stanislav Dolganov), Patch 2016-08-17, 2/4 https://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197902.html or https://gist.github.com/theacetoace/1440449c7dc6cb34f4dc797c9bda3e62 (this one appropriates Snow OBMC)

Artoria2e5 avatar Feb 24 '24 07:02 Artoria2e5