Daemon404

8 ms·

31.
by Daemon404 9y ago
The AOM engineering list and kavi tracker is restricted to members of organizations in AOM, as far as I am aware.
32.
by Daemon404 9y ago
I was mistaken, one is already written, but not merged. So we're already in bikeshed mode ;)
33.
by Daemon404 9y ago
The bitstream isn't frozen yet. As an aside: A wrapper within FFmpeg for libaom is only a few hours work, but if you want to play with it Right Now, VLC has support. A native decoder will indeed take significantly longer though.
34.
by Daemon404 9y ago
There is concerted effort on the AOM list to finish and close all bugs or features that require normative bitstream changes, so I would expect it isn't too much longer. The number of remaining issues is small-ish, but not zero. The i
35.
by Daemon404 9y ago
> I am more looking forward to future release. The current version is mostly a bitstream freeze. It's not even a bitstream freeze. This 'release' was put out by the marking folks, and wasn't even discussed with people
36.
Writing x86 SIMD using x86inc.asm(blogs.gnome.org)
1 points by Daemon404 9y ago|0 comments
37.
VideoLAN Dev Days 2016 Talks(youtube.com)
1 points by Daemon404 10y ago|0 comments
38.
by Daemon404 11y ago
FFmpeg would seem to already have this: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/a...
39.
by Daemon404 11y ago
I cannot imagine it truly is - it uses a variation of CABAC, which sure has patents related to it. I wonder if they had a real legal person OK that claim.
40.
Problems and Solutions for Interaction Between C and Go(gist.github.com)
1 points by Daemon404 11y ago|0 comments
41.
by Daemon404 11y ago
Nothing bad ever happens to proprietary database software... nope.
42.
by Daemon404 11y ago
Dang, I always figured that would be unsafe eventually. I wonder, does this make stuff like this unsafe: var thing C.thing; C.somefunc(&thing) i.e. can stack address change now?
43.
by Daemon404 12y ago
Sure, but that requires knowledge of how LLVM works. Some dude checking out the language probably doesn't.
44.
by Daemon404 12y ago
Perhaps I scanned too quickly. I probably missed since there is no actual mention of ABI (or e.g. which calling conventions it supports on what platforms). The page is confusing - it seems to discuss ABI and syntax and stuff, which isn&#x
45.
by Daemon404 12y ago
I can't find any mention of if they provide a C-compatible ABI. Kinda useless as a systems language if they don't - you can't call it from anything else.
46.
by Daemon404 12y ago
> It is not difficult to get some kind of honorary position with a research institute when you work in industry. I think this statement is uh... a tad misleading. This depends a lot on your particular field of interest/research an
47.
by Daemon404 12y ago
Hey, I'm 'Daemon404' on FreeNode and Mozilla IRC, or you can grab my FOSS email from my GitHub account or FFmpeg/Libav's git repo.
48.
by Daemon404 12y ago
mozjpeg has such a bug opened too: https://github.com/mozilla/mozjpeg/issues/8 This isn't exactly new ground beign covered here, nor is it tied to one image format, so I wish people would be a little les
49.
by Daemon404 12y ago
You ought to take a look at jpeg-archive: https://github.com/danielgtaylor/jpeg-archive (the bbcq-like is similar to jpegmini's weighting).
50.
by Daemon404 12y ago
I agree, and as stated in my other comment, I believe it needs downstream support to be adopted properly. To that end I plan to add support to ImageMagick, and perhaps write a PS plugin.
51.
by Daemon404 12y ago
I am waiting until 3.0 when they roll out their plan for ABI compatibility (it currently masquerades as jpeg62 but is not compatible), and decide on a defacto way to detect if you are building against vanilla libjpeg(-turbo) or mozjpeg (cur
52.
by Daemon404 12y ago
You can 'optimize' encode-time by using better chroma downsampling, but really the issue is usually on the client side upsampling (a lot of libs use terrible nearest neighbor for 'speed'). As for trellis, you should play
53.
by Daemon404 12y ago
It should be noted, since it is nowhere to be seen in this post, it breaks API and ABI while still presenting itself as libjpeg version 6 to the system, which is very evil. Open Issues: https://github.com/mozilla/mozj
54.
Open Source JPEGmini Clone(github.com)
1 points by Daemon404 12y ago|0 comments