This will be my last post to a-hackers-craic!
I've moved all the posts and images to http://www.zedzone.space/blog, although how they look and how they work are still very much work in progress. I had already moved most of http://users.on.net/notzed to http://www.zedzone.space yesterday.
Some things might be broken for a while but everything apart from comments should have already made it across intact.
Byeee.
I didn't really find anything I liked so instead i got myself a domain and a virtual private server to play with. I had originally intended to set something up on my home network via a static address but I never got around to it. Unfortunately getting a vps in switzerland is cheaper than even doing that - and that's with the virtual hardware and unlimited network bandwidth the latter of which is big buckeroonies in australia.
Well I still haven't done anything with it apart from setup apache with a nothing homepage pointing back to my isp hosted stuff, but it's at www.zedzone.space.
I'm still pretty lazy on the whole idea so it might take a while but i'll move my code and blog and eventually add an email to it. I don't particularly like working at that end these days (despite multiple shots at CMS subsystems) - too much security and complexity to worry about - but i'll see how it goes.
Although logging in here to post this did give me pause for thought on getting a bit less lazy about it. Despite never having offering it before blogger just gave me a page to buy and link a custom domain for a-hackers-craic.
Thanks google for once again mining my email to sell me something I already bought!
Next it'll be combat boots, kilts, and beer ... Adelaide Review article which includes bits about me (not sure why i didn't introduce myself as Zed that time, would've been better!).
Update: 15/4/2018. I finally got off my laze arse and spent a wet afternoon playing with the site - i've copied my internode (ISP) pages to the server, fixed some paths, and installed cvstrac for browsing the source (of some of the projects) via the new virtual host code.zedzone.space.
Still to do is the blog.
I haven't seen any patches for my laptop or work computers so far - one because i don't run any av software on microsoft? Ugh, what a fucking mess. I barely use that machine any more anyway, even less so while running that junk.
What's most appalling is that the problem has been sat on for 6 months under "responsible disclosure" while intel continued selling gimped hardware based on bogus benchmarks. And yet the linux and *bsd developers are either only just starting on or working on cleaning up fixes very recently - even intel is still fucking around with microcode updates.
The tech press, apart from The Register (who really broke this story) has been pretty shithouse too. "big nothingburger" for a massive massive security hole that isn't actually fixed by any of these OS kernel patches, merely mitigated. It's a big big serious problem, with big big serious costs, and the handling the disclosure has been an utter disaster - seemingly designed to spread fud about the impacts and costs. Still, if you relied on a single supplier - and particularly a nefarious piece of shit company like Intel - for any serious hardware investment, sucked in I guess? We all have to pay for your stupidity in the end regardless.
Blah.
I was insomniac[sic] late night and bored so I took the latest stack overflow survey. Apart from some pretty strange questions it's pretty clear why nobody reads my blog - no mention of almost any of the technologies I use day to day. Well at least they had the brains to identify C and C++ as two separate languages I suppose.
Some of the "order these in importance to you" questions I just skipped - I didn't care about the topic at all. A minor problem was a bit of confusion with "framework" "language", etc - where would OpenCL fit if they even included it? No CUDA either for that matter. Plenty of questions about advertising. No I don't use an ad-blocker but I turn off javascript which makes the site oh so much faster and kills most adverts as a bonus.
Sleep has been pretty miserable lately - probably a side-effect of overdoing it a bit, but I think i've gained enough weight again for the sleep apnoea to kick in. One example of overdoing it was the last weekend. Hit the beach Saturday afternoon, dropped in at a mates place - drank a carton of (bloody expensive) piss, went to a party (total strangers apart from him), was up all night whilst everyone else was falling asleep, back to his place to pick my bike up - for a couple more, another dip, and finally dropped by the pub on the way home for a fast (very slow!) one. Barmaid thought i was managing well all things considered but maybe that's because I always look exhausted and feel like shit? Nothing like a 36 hour day to get you tired; and then I was awake after only 4 hours of bloody sleep. For a couple of silly reasons I also got sunburnt to a crisp, oops.
Finally kicking into summer mode!
Pretty much recovered from NYE and NYEE drinking but I might take it easy for a couple of days. Waiting for the weather to heat up enough to get back to the beach, did some gardening. The replacement BIOS arrived today so I resurrected my PC too - still seems a bit funny so i'll probably get another one soonish but it works again for now.
I found a laser printer dumped on the side of the road so took it apart for something to do. Surprising amount of screws, custom springs, cogs, and lots and lots of tough plastic. Probably nothing I can do with it but the imaging unit is kinda cool - rotating mirror, a couple of lenses and mirrors. I suppose the more surprising thing is how much technology is placed in what is essentially a throwaway, one-use device. The "consumable" isn't the toner in these things, it's the whole machine; and what's worse is the realisation that the economies of scale mean it couldn't be done any other way. The world is so fucked.
When I wrote the following on the new jjmpeg home page:
Version 3+ is a complete rewrite from earlier versions which have effectively dissapeared from the internet after google code closed down.
I didn't realise just how true it was. Without google code and regular blog updates my projects have basically vanished from the internets - and more so from google search than others. I'm not particularly surprised there is no real interest in the projects themselves but effectively vanishing is a bit weird. Unless you're using some proprietary publishing platform you essentially don't exist.
Well i've got a few weeks off at least anyway; i'll take a break from the computer, watch some cricket, and basically just bum around a bit.
Put enough together to push out a release of jjmpeg.
It ended up 1700 lines of Java, 2000 lines of C, and 300 lines of Perl.
Apart from supporting the latest version of FFmpeg (at least when I started a couple of weeks ago), it's smaller, cleaner, and more complete than any previous version. Having said that this is essentially just a beta release.
This one is licensed GNU General Public License Version 3 (or later).
I've kinda had enough for the moment so it's a pretty bare home page, but it's there.
Merry XMAS!
One of the things I did was fill out/sync up the important enums - AVCodecID, AVPixelFormat, AVSampleFormat, and so on. Previously the pixel format and sample formats were also Java enums - which can be convenient at times and provides some more (albeit much much overvalued) 'type safety'.
This was fairly easy because the PixelFormat was a simple densely ordered C enum so i could map between the two with a simple +-1. Unfortunately someone decided to add a big hole in the middle of it sometime between 0.10 and 3.4, ... so I gave up and just converted it to a class holding static final int's, and to make it consistent I did that with the other enumerations as well. It doesn't really make the classes any harder to use and improves the class size and memory footprint. I just added some methods to access libav*'s metadata information so I can still map between string representations and so on.
I had to add a small compilation stage which extracts the enums from the header files and converts them to a C file which when compiled and run produces the Java source ... this seemed the absolute shortest path to ensuring I got accurate numbers based on the ffmpeg build configuration.
So after about a weeks worth of solid work it's grown somewhat (about 2KLOC Java, and 2KLOC C, counting lines with ";{}") and the TODO list is getting pretty short.
I would like to clean up the exception design a bit - unfortunately i'm just not very good at that (who is?) but i'd like to get better. The build system is clean and simple but could be improved and needs to include the aforementioned enum stuff, a dist target and versioning. Logging would be nice (both redirect ffmpeg to java.util.logging and some for jjmpeg itself). JJMediaWriter? Fix the license headers, add at least a README.
Not today though, today I drink.
So I guess the mood took me, I somehow ended poking away until the very late morning hours (4am) the last couple of nights hacking on jjmpeg. Just one more small problem to solve ... that never ended. Today I should've been working but i've given up and will write it off, it's nearly xmas break anyway so there's no rush, and i'm ahead of the curve anyway.
I got this ported over and playing video fairly easily, and then went through on a cleanup spree. I removed all the BufferedImage, multi-buffering, and scaling stuff and a few other experiments which never worked. Some api changes allowed me to consolidate more code into a base class, and some changes to AVStream necessitated a different approach to initialising the AVCodecContext (using AVCodecParameters). I made a few other little tweaks on the way.
The reason I removed the BufferedImage code is because I didn't want to pollute it with "platform specific" code. i.e. swing, javafx, etc. I've moved that functionality into a separate namespace (module?).
My first cut just took the BufferedImage code and put it into another class which provides the functionality by taking the current AVFrame from the JJMediaReader video stream. This'll probably do but when working on similar functionality for JavaFX I took a completely different approach - implementing a native PixelReader() so that the native code can decide the best way to write to the buffer. This is perhaps a little more work but is a lot cleaner to use.
jjmpeg1 lets you scale images 'directly' to/from primitive arrays or direct ByteBuffers in addition to AVFrame. Since they have no structure description (size, format), this either has to be passed in to the functions (messy) or stored in the object (also messy). jjmpeg1 used the latter option and for now I simply haven't implemented them.
The PixelReader mentioned above does implement it internally but for code re-use it might make sense to implement them with the structure information as explicit parameters, and use higher level objects such as PixelReader/Writer to track such information. On the other hand the native code has access to more information so it also makes sense to leave it there.
I went a bit further and created a re-usable super-class that does most of the work and toolkit specific routines only have to tweak the invocation. This approach hides libswscale behind another api. The slice conversions don't work properly but they're not necessary.
So far I had public constructors and `finalisers' because otherwise the reflection code failed. That's a bit too ugly (and `dangerous') so I made them private. The reflection code just had to look up the methods and set them Accessible.
Constructor cc = jtype.getDeclaredConstructor(Long.TYPE);
cc.setAccessible(true);
return cc.newInstance(p);
Whilst working on JJMediaReader I hit a snag with the issue of ownership. In most cases objects are either created anew and released (or gc'd) by the Java code, or are simply references to data managed elsewhere. I was addressing the latter problem by simply having an empty release() method for the instance, but that isn't flexible enough because some objects are created or referenced the the context determines which.
So I expanded the Java-side object tracking to include a `refer' method in addition to the 'resolve' method. `resolve' either creates a new instance or returns and existing one with a weak-reference object which will invoke the static release method when it gets finalised. `refer' on the other hand does the same thing but uses a different weak-reference object which does nothing.
I then noticed (the rather obvious) that if an object is created, it can't possibly 'go away' from the object tracking if it is still alive; therefore the `resolve' method was doing redundant work. So I created another `create' method which assumes the object is always a new one and simply adds it to the table. It can also do some checking but i'm pretty sure it can't fail ...
If on the other hand the underlying data was reference counted then the `resolve' method would be useful since it would be possible to lookup an existing object despite it being `released'. So i'll keep it in CObject.
As part of this change I also improved CObject in other ways.
I was storing the weak reference to the object itself inside the object so I could implement explicit release and to avoid copying the pointer. I removed that reference and only store the pointer now. The WeakReference it already tracked in a hash table so I just look it up if I need it. This lets me change the jni code to use a field lookup rather than a function call to retrieve it (I doubt it makes much perf difference but I will profile it at some point).
I also had some pretty messy "cross-layer" use of static variables and messy synchronisation code. I moved all map references to outside of the weak reference routine and use a synchronised map for the pointer to object table.
For explicit release I simply call .clear() and .enqueue() on the WeakReference - which seems to do the right thing, and simplifies the release code (at least conceptually) since it always runs on the same thread.
