<br><br>On Wednesday, March 9, 2022, Phyllis Smith <<a href="mailto:phylsmith2017@gmail.com" target="_blank">phylsmith2017@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">so I  played around with vp9 enciding a bit more.<div>apoarently there is vp9 lossless mode, and additionally libvpx can support high bit depth if configured so. </div></blockquote><div style="font-size:small">Tested on my laptop and the lossless file is, as expected, 15 times larger but looks better.  Thank you Andrew.</div><div style="font-size:small">Will compiling with vp9 multibit affect any loading or rendering of vp8/vp9?  I will try to check this and test it too.<br></div></div></div></blockquote><div><br></div><div>not sure why this still not default - may be due to libvpx size or speed? <br></div></blockquote><div><span class="gmail_default" style="font-size:small">Good news.  The directory containing the libvpx code is only 4 M larger and the bin/cin file is just a little bigger (about 150KB if I calculated it correctly) with the patch in.  But I did not check the compile speed yet.  File size differences are in:</span></div><div><span class="gmail_default" style="font-size:small">96K     ./vpx_scale/generic<br>144K    ./vpx_scale<br><br>424K    ./vp9/encoder/x86<br>4.0M    ./vp9/encoder<br>420K    ./vp9/decoder<br>68K     ./vp9/common/x86<br>1.0M    ./vp9/common<br>5.8M    ./vp9<br><br>2.6M    ./vpx_dsp/x86<br>7.0M    ./vpx_dsp<br></span></div><div><span class="gmail_default" style="font-size:small"><br></span></div><div><span class="gmail_default" style="font-size:small">There are these files that maybe can be gotten rid of in the compile if there are options for that if necessary later:<br></span></div><div><span class="gmail_default" style="font-size:small"></span></div><div><span class="gmail_default" style="font-size:small"></span>3.3M    ./docs<br>240K    ./examples<br>1004K   ./third_party/googletest<br>448K    ./tools</div></div></div></blockquote><div><br></div><div> I think I created small local hack fir deleting all *. o files, just run this line from thirdparty dir after all components built successfully:</div><div><br></div><div>objrem:</div><div>        find . -type f -name '*.o' -delete</div><div><br></div><div>{from thirdparty/Makefile} </div><div><br></div><div>this way you will have a bit more space for building/linking cingg itself</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div><div style="font-size:small" class="gmail_default">More good news is that 1 test rendering the same file with the enable in and with the enable out came out exactly the same.</div><div style="font-size:small" class="gmail_default">Now on to testing 0002-Remove-libavdevice ... by Andrew.<br></div><br></div></div></div></blockquote><div><br></div><div>if this change does not break normal cingg input/output it may even balance out prev. change in terms of compilation soeed and size </div><div><br></div><div>I wonder how much slower vp9 profiles become if you choose 10/12 bit vp9? </div><div>And how quality of encode/decode compare with normal 8bit vp9.. but this is not urgent. </div><div><br></div><div>ps: you also hoped to push jp2.dfl file? </div>