Archive for October, 2024

MPEG-4 ASP: done for now

Tuesday, October 15th, 2024

In my last post I mentioned I need to deal with MP3 in AVI and multi-threaded decoding. The former turned out to be a simple bug (I should’ve not trusted AVI header reporting 12-bit audio), and I gave up on the latter.

The main reason for that is what seems to be the main contribution of MPEG to the world of video coding, namely B-frames. While the idea behind them is reasonable (to code scene transitions or smooth movements as an interpolation between two keyframes), practical implementation brings headaches because those frames are coded in an order different from the display order (after all, you can’t interpolate between two frames if you haven’t decoded both of them). And of course it got worse in H.264 and later codecs where B-frames can reference other B-frames so you need to code information about the frame structure (references and how to update them).

And the problem with MPEG-4 ASP is that while it can have B-frames, its popularity it tied more to AVI container which lacks means to signal frame reordering (fun fact: the MPEG-4 ASP video files in MOV that I have would be perfect candidates for B-frames but lack them entirely). Of course later there other containers gaining popularity like Matroska or OGM (or even MP4 occasionally) but the gilded age seems to be tied to AVI. And of course that created difficulties.

If you have I- and P-frames only, there’s nothing to care about—but multi-threading won’t be that effective either. Newer implementations (Xvid 1.3.7 is rather fresh BTW) output B-frames as is so good luck knowing that in advance and performing reorder. In this case I see if the coded timebase is the same as the one reported by the container and simply re-assign timestamps from the bitstream (and if this does not work—well, tough luck). But there was a funnier intermediate solution with one frame containing data for both P- and B-frame and the following frame being a skip frame, so a decoder could replace it with an appropriate frame. This reminds of Indeo 4 which performed the same trick. And making that a multi-threaded decoding would be a mess requiring either saving frame data and scheduling it for later decoding or scheduling both frames and then trying to tie it to the upcoming frame decoding request. And playing back typical video takes about 20% of CPU load…

Thus I’ve committed what I find to be good enough for my needs and I shall forget about it—at least until some decoding artefact will annoy me enough. There’s more boring and unremarkable stuff I want to do on NihAV, working on this decoder reminded me that it can always be worse (or uglier).

P.S. For some reason repository cloning or updating from git.nihav.org still does not work (but the web interface is fine). I’ve reported the problem and hopefully it will be resolved soon. I suspect that the provider blocked it because of too many synchronisation requests from other sites trying to mirror the repositories. In either case I’m still grateful for the hosting.

Posted in NihAV, Various Video Codecs | No Comments »

Woes of implementing MPEG-4 ASP decoder

Friday, October 11th, 2024

So, for a last month or even more (it feels like an eternity anyway) I was mostly trying to force myself to write a MPEG-4 ASP decoder. Why? Because I still have some content around that I’d like to play with my own player. Of course I have not implemented a lot of the features (nor am I going to do that) but even what I had to deal with made me write this rant.
(more…)

Posted in NihAV, Useless Rants, Various Video Codecs | 4 Comments »

Another bunch of formats I’m not looking at

Saturday, October 5th, 2024

I regularly look at the dexvert list of unsupported video formats to see if something curious comes up. About half of that list are formats supported by na_game_tool, maybe a third are animation systems (i.e. more like a script language telling how to compose and change external or internal resources), but the rest are formats that pique my curiosity. I’ve written about some of them (like Amiga formats I blogged about half a year ago or rather recent TealMovie) and today I’m going to mention some more.

First of all, AVS. That’s the third AVS format I’m hearing about. First there was AVS used in Creature Shock game, then there’s this Chinese MPEG-四 AVS (followed by AVS2 aka HEVS and AVS3 aka “VP9VVC by any other name…”). Apparently there’s another one, from early PC era. It seems to have been used by some ActionMedia cards with Indeo video compression formats (DVI PLV and DVI RTV, also PIC and JPEG are mentioned in the convertor) and audio (8-bit PCM or DVI ADPCM). There’s a special tool for converting AVS to AVI but good luck finding samples (I’ve found one, yulelog.avs, used in a demo). The format seems to be documented (as DVI format) but the codecs are not (beside RTV 2.0 aka Indeo 2). Maybe I’ll take another look at it one day…

Then, there’s a game called Music Chase. I found it by accident looking for Toon Boom Studio samples (which is an animation system, so not so interesting to look at). So what’s interesting about this game?

It looks like the game assets are divided into rooms, each having its own set of resources—usually some TBP files, some TMV files and a MID file or two. The first format is the standard BMP with compression method 21 (which is not). TMV files are ciuQmiTke MOV (i.e QuickTime format but with all values being little-endian now) and custom track handlers so while you can recognize audio track, video track is not so easy. Additionally the helper DLL is 16-bit code that makes Ghidra decompiler give up on almost every function. So maybe I’ll return to it when I’m seriously bored but not today.

Still, it’s nice to encounter such formats time from time.

Posted in Various Video Codecs | 4 Comments »

Looking at Winamp codebase

Friday, October 4th, 2024

Breaking news from the Slowpoke News Channel™: a source code base for Winamp has been released (just last month). So it’s a good occasion to talk about it and what interesting (for me) things can be found in the third-party libraries.

I think I used the software a bit back in the day when MP3 was still rage (and there were CDs sold proudly featuring MP3 at 256kbps) and I still was using Windows (so around 1998-1999). I even briefly tried K-Jofol player (does anybody remember that?) but I didn’t see much point in that. About at that time I finally switched to Linux as my main OS and started using XMMS and XMMS2 (I actually met one of its developers at FOSDEM once—and saw a llama or two when I visited a zoo but that’s beside the point). Also there was a plugin for XMMS2 that added VQF support (again, nowadays hardly anybody remembers the format but it was an interesting alternative; luckily Vitor Sessak reverse engineered it eventually). But with the time I switched to MPlayer for playing music and nowadays I use my own player with my own decoders for the formats I care about (including MP3).

But I wanted to talk about the code, not about how little I care about the program.

First fun thing is that the source code release looks like somebody was lazy and thinking something similar to “let’s just drop what we have around and tell not to do much with it—it’ll create some hype for us”.

Second fun thing is that it fails to live up to the name. As it should be obvious, the name comes from AMP—one of the earliest practical MP3 decoders (the alternatives I can remember from those times were dist10 or the rather slow Fraunh*fer decoder). And of course WinAMP uses mpg123 for decoding instead (I vaguely remember that they switched the decoding engine to the disappointment of some users but I had no reason to care even back then).

But the main thing is that they’ve managed to do what Baidu failed to do—they’ve made VP5 decoder and VP6 codec open-source. Of course it may be removed later but for now the repository contains the library with the traditional Truemotion structure that has VP5 decoder as well as VP6 decoder and VP6 encoder. So those who wanted an open-source VP6 encoder—grab it while it’s still there (and I still have my own implementations for either of those things).

Out of curiosity I looked at the encoder and I was not impressed. It has more features (like two-pass encoding) and more refined rate control but it does not look that much better. I wonder what Peter Ross could say about it, being a developer of a popular and well-respected encoder for a codec with rather similar structure.

Overall, the code base looks like a mess with no clear structure, with most libraries shoved into one directory without any further attempt to separate them by purpose. But it does not matter as it was not intended for the large collaborative efforts and two or three programmers could live with it.

Still, let’s see if something good comes from this source release.

Posted in TrueMotion, Useless Rants | 8 Comments »