Since I had nothing better to do I was browsing FMV games at archive.org and in one of them I found rather peculiar sample: avconv has wrong palette for the first half of it and nihav-tool has wrong palette in the second half of the clip. And I thought that MOV is not supposed to have palette changes at all.
It turned out they used a multiple sample descriptors trick: it’s possible to provide several codec descriptions for one track and use one or another for different frames. That file has two descriptors for the video track with different palettes. Mystery solved.
And it also solved another mystery with a different file from that game where some frames are not decoded properly. It turned out that it also has two sample descriptors for the video track: one is A**le Graphics and another one is Cinepak.
Back in the day I ranted that MOV is too flexible and this proves once again how true that is. Good thing I don’t have to care about supporting such files properly.
This sounds interesting and cursed. Do you have links to these samples?
As for horrible MOV features, the format supports panoramic pictures and even 3D meshes if I’m not mistaken.
Oh and an ELBG update: using k-d trees indeed speeds it up, by just over 50%. The gains are limited because the ELBG “shiftings” stage ends up taking the majority of the time. Disabling it results in LBG, which is faster but also worse quality.
It’s Virtual Nightclub game for sure (
archive.orghas a ZIP file with an installer inside that hasDosBoxplus two CD images that have those wonderful clips. And if you browse other FMV games you can find QTVR files as well which is also something I’d rather not touch.And one would think ELBG shift stage is exactly where rough cluster caching should help (IIRC we need to consider just the neighbourhoods of two cells and recalculate distortions just there—after all even if it’s not completely accurate that’s mostly for the final decision on moving an underutilised codeword to a heavy duty cell or not).
Nice find (and even better analysis). Reminds me of how painful MOV can be to work with. Also makes me wonder what software generated this file, and why it made this decision? Or was it a conscious tweak on the part of the creators, using all the dials of the creation software?
I don’t think the software used to create those files left a mention inside (so maybe it was QT Pro, not Premiere Pro). My theory is that they decided to concatenate separate segments that required palette change and (at least in one case) a segment was encoded with a different codec by mistake. But as QT player did not care neither were they.
I guess re-encoding those cinepack fragments on something like 68030 will take a lot of time, so “glue two files at editing” sounds quite natural trick to invent and use..
Yes, but the files in question are rather paletted SMC (which makes more sense to glue) with an occasional Cinepak segment. Hence I think it was rather done by a mistake.
> horrible MOV features
don’t forget QuickTime Effects track
Can we please forget that? And aliases/external references? And multiple edit lists? Let the professionals enjoy it.