lör 2019-01-19 klockan 22:40 +0000 skrev Matthew Fearnley: > > On Tue, 25 Dec 2018 at 09:35, Tomas Härdin <tjop...@acc.umu.se> wrote: > > > lör 2018-12-22 klockan 15:32 +0000 skrev Matthew Fearnley: > > > > > > > > > > > > > > > > Note that bw,bh aren't guaranteed to equal ZMBV_BLOCK, so > > > > `histogram[0] == > > > > > bw*bh` would have to be used to guard against those (literal) edge > > > > cases. > > > > > > > > Right, yes. But if we have block sizes other than ZMBV_BLOCK^2 then we > > > > need score tables for those sizes too. > > > > > > I’ve thought about that a bit. I wondered if it would be worth it given: > > > - the extra code, memory and logic needed > > > > If you have a huge amount of DOS captures to optimize then it might be > > worth it, else probably questionable > > > > > - it would only improve the edge blocks > > > > I imagine large blocks would be good for scenes with mostly global > > motion. You cut down on the number of MVs and thus the amount of data > > zlib has to compress, if the block size is a good fit. > > > > > - the existing score table isn’t catastrophically bad for short blocks, > > > > and would still favour blocks with more common pixels. > > > > > > It would be better from a correctness perspective though, and effects on > > > > running time should be negligible. > > > > Good point. There's also no telling whether the current model is > > actually an accurate prediction of how zlib behaves :) > > > > > > Hi. Just to say, I tried setting up additional score_tabs for the > bottom/right partial blocks. Unfortunately, after implementing it and > ironing out the bugs, the new score tables actually caused a slight > increase in file size! > After a little informal investigation with a couple of videos, my findings > were that increasing the divisor - '(i / (double)(ZMBV_BLOCK * ZMBV_BLOCK * > some_factor))' - would generally lead to slight compression improvements. > Given the score table is still "valid" for smaller blocks, and given the > extra complexity of adding the score tables, plus the fact that it may > generally hurt the compression, I'm inclined to leave it with the one score > table. But there may be potential to improve the current compression > method in future, by somehow tuning the divisor for better results > generally.
Huh, that's strange. Sounds like something that warrants a comment in the code. I also see we have an answer do Carl's question: you're still experimenting with this :) I think we can hold off on pushing anything until you feel happy with the result /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
