rav1e
rav1e copied to clipboard
xiph
Signal interp_filter in the bitstream.
Coverage increased (+0.05%) to 75.472% when pulling e1c3f48c45da0676251fd2e7739857f4b124bcc1 on tdaede:interpfilter into edbc586999d6a1e49e1e35d84a0c8a2c9dcf7990 on xiph:master.
about a 0.04% loss https://beta.arewecompressedyet.com/?job=interpfilter-2019-08-09_175924-f3c43a4&job=master-ec0c7787dd1598f4cecaedda2a120ff4ab0eb6d0
I might have seen this PR, but was not able to recall this much progress is already there. I hope we want not to waste this PR and land of most of it please.
When you rebased on master today, was there still desync? I think it should not be there. Since https://github.com/xiph/rav1e/commit/485d179206e3a777db95157a5b25a1a3b1991a8e# Before 485d179206e3a777db95157a5b25a1a3b1991a8e, frame header still have default filter written when your PR set is_switchable_filter = true, that I believe can cause desync.
@tdaede Would you have plan to follow up the build errors (mismatch) soon, or might be later after your current other work?
@ycho I will look at it a bit today, but if I don't find a fix I'd appreciate it if you could also look.
@ycho I will look at it a bit today, but if I don't find a fix I'd appreciate it if you could also look.
Sure, I wanted to help on this. Just I got completely taken by my son during thx giving holidays. Also, I think I plan move on this after trying fixing desync one #1858.
With local testing, this causes corruption from 2nd frame, either speed 0, 6, or 10. I expect speed 10 does not encode filter type per blocks, since its block size is 64x64 >= 32x32 checked by needs_interp_filter(), other than right or bottom frame borders.
Testing with: ./target/release/rav1e nyan.y4m -o test.ivf -r test_rec.y4m --quantizer 50 --speed=0 --limit=30 ./target/release/rav1e nyan.y4m -o test.ivf -r test_rec.y4m --quantizer 50 --speed=6 --limit=30 ./target/release/rav1e nyan.y4m -o test.ivf -r test_rec.y4m --quantizer 50 --speed=10 --limit=30 only 1st frame is decodable.