Since the last time I’ve done some more boring stuff for NihAV, more precisely 10-bit H.264 decoder and extended MOV support.
The former is more or less straightforward but it made me regret Rust lack of text-level macro processing. The problem is generating almost identical code for various combinations of bitdepths that differ only by the clipping range and function name suffixes. Probably it can be solved with proc macros but that’s a hole I’m unwilling to jump into. Also supporting both 8- and 16-bit decoding in one module is annoying, so I ended up just putting them next to each other and selecting one for the current mode of operation. This also uncovered the fact that my scaler did not handle high-depth YUV in the most cases, so I had to fix it too. And the ironic thing is that I don’t have enough content to watch in that format (and a couple of sample files I have are Matroska with FLAC audio, which can’t be remuxed to MP4, so there’s that).
In other rather equally useless things, I’ve finally made a MOV muxer for na_eofdec. Of course it’s a simplified one, supporting only raw video and audio tracks, but even that was annoying to support properly (I’m still not sure if I do support it properly). At least when the bitterness passes I should be able to make a MOV muxer for NihAV (and who knows, maybe even implement some QT encoders to exercise it).
But that’s not all regarding MOV. In a recent post I mentioned the oldest known MOV flavours. Finally I’ve managed to extend my MOV demuxer to support beta version of it (it’s still MOV but with a few different details here and there) while alpha version was easier to support in a different demuxer written from scratch. If you’re curious, those files are short clips (about 15 seconds usually) compressed with QT RLE demonstrating some features of upcoming System 7 in rather symbolic form. Here’s a GIF of virtual memory feature presentation.
That’s about it for now, I hope to do more exciting things next. For instance, add some Amiga formats to na_eofdec. And most importantly, Paul told me about new RAD Audio codec which I still have to look at thoroughly. From a first glance while audio in Bink is a lot like MPEG Audio Layer II (i.e. simply quantise and write coefficients with a fixed amount of bits), this new codec is more akin to AAC LC as it apparently has long/short frames division and (at least two) Huffman tables for coefficients. Another change is that Bink audio was stored in simple container formats with fixed structure, new format looks more like an elementary stream with as few bits as possible spent on coding different fields. Let’s see how it turns out…
Your system is falsely accusing me of spam. This is not spam. It contained URLs that are not spam but are now destroyed.
Hi, do you still look at codecs and try to figure them out?
I have one for you, its quite something of a mystery, all I know is that it’s DCT based somehow, it is called Apple MVS, and it’s used in the VNC protocol for Mac OS X Screen Sharing. It appears to be combination lossy and lossless (or near lossless). The server will send a lossy image first and then if there is enough bandwidth and the picture is static it will then “clarify” the lossy image with a much better one.
We would like to try and figure this codec out so that we can document it for RFBproto project (URL Destroyed, go to github and search rfbproto) and then it may be implemented into some open source viewers.
If you have any interest in this I can provide: pcap files of an unencrypted VNC session using the MVS codec, and access to a live Mac OS Screen Sharing server. One 3rd party has cracked this codec but they did not document it, instead implemented a closed source client called “Remote Desktop Manager”. But they have a free personal use version and their client runs on Linux, Windows, Mac, and phones. The only server and only other client are the Apple ones for Mac OS only.
It’s not my system (and quite likely it’s the plug-in responsible for spam checking). I suppose since spammers tend to post links while normal people less so, it overreacts (even on more regular posters). Maybe you can use
hxxxs://or something like this to make it pass next time.Those
.pcapfiles may help but I’d probably learn more from the binary specification. I suppose you meant RDM from a company which name is the opposite to evolution, so maybe I can extract it from there (but having the original component may be better). And since I usually work by figuring out stuff from static things, I shan’t need an actual connection.Just don’t expect fast results, it may take a lot of time merely to locate the code responsible for the codec inside those large modern binaries let alone the rest.