xooyoozoo

8 ms·

1.
by xooyoozoo 12y ago
If your browser supports VP9, that will be forced whenever possible. I'm not sure if switching to CPU-only video decode will be a net gain for most.
2.
by xooyoozoo 12y ago
He either made his judgement based on non-obvious criteria or, more likely, looked at x265 at the "wrong" moment. Right before libbpg was announced, x265 had several commits fixing large 10bit and 422/444 bugs. As far as intr
3.
by xooyoozoo 12y ago
>It will remain slower than x264 though, it uses more cpu consuming algorithms in order to cram out more 'quality per bit' At an abstract level, HEVC is AVC + refinement + new algorithms. Conforming bitstreams aren't requi
4.
by xooyoozoo 12y ago
Octane is Google's own benchmark suite. I don't think getting beaten on your own hand-picked set of performance metrics satisfies any definition of "impressive".
5.
by xooyoozoo 12y ago
There's a recent paper comparing subjective performance between HEVC and VP9. http://www.scribd.com/doc/238049197/HEVC-H-265-VP9-AVC-subje...
6.
Google's web video ambitions bump into hard reality(cnet.com)
47 points by xooyoozoo 12y ago|36 comments
7.
by xooyoozoo 12y ago
>using new process node - 3D 16nm The Hotchips slides explicitly mentioned 20nm. Based on a bad assumption, the author for this story decided to freely reinterpret '20nm' as 16FF. (There's a connection between the two, but
8.
by xooyoozoo 12y ago
"Helping The Web" in this case would be choosing the video format with the broadest support base... which in this case is H264. The only holdouts are Opera and a couple variants of Firefox. As a bonus, you'd get hardware acce
9.
by xooyoozoo 12y ago
Because of actual semantic analysis or some microbenchmark you saw somewhere running on a beta, unstable compiler?
10.
by xooyoozoo 12y ago
And those libraries will likely be OpenCL-based and nicely portable to Intel's Xeon Phi options.
11.
by xooyoozoo 12y ago
Interestingly, the gif->mp4 in the source link uses Constrained Baseline H264, the only profile that's supported by Cisco's BSD-licensed OpenH264[1]. The MPEG-LA patent fees are already covered, so that small projects can freel
12.
by xooyoozoo 12y ago
I recall reading on gfycat's subreddit that desktop Chrome's H264 support is occasionally spotty, so they chose to force on VP8/WebM in Chrome. The upside is that users get a reliable experience. the downside is that laptop C
13.
by xooyoozoo 12y ago
Go's compilation was fast, which made developement much more pleasant. Performance of the actual compiled code was a different matter (hard to get both fast binaries and fast compilations). However, I understand that 1.1 and 1.2 has
14.
by xooyoozoo 12y ago
JpegMini claims to be perceptually lossless, not mathematically lossless.
15.
by xooyoozoo 12y ago
It's 100% boilerplate. The whole "handicapping" debate that pops up every ICC thread is likely several years out of date (not that I don't expect to see it again and again for the next decade or two). Case in point, take
16.
by xooyoozoo 12y ago
I don't use or know about any of the other tools mentioned, but Pandoc isn't exactly someone's pet project. It may be niche , but it's not unknown. If you need to convert markdown/rest/latex/etc to pdf&#x
17.
by xooyoozoo 12y ago
[T] => Vec<T> It's ~[T] that is now Vec<T>, which was a good change in emphasis (the former is still valid, though it will become Box<[T]> with this RFC). Besides the implementation differences, I think readabi
18.
by xooyoozoo 14y ago
> If there were a way to optimize things better than x264 has, it almost certainly requires working directly within the encoder's analysis code itself rather than carrying out a pre-encoding analysis process and then fiddling with roug