[FFmpeg-devel] Psygnosis YOP decoding

Thomas Higdon thomas.p.higdon
Fri Aug 7 07:05:41 CEST 2009

On Fri, Aug 7, 2009 at 12:43 AM, Vitor Sessak<vitor1001 at gmail.com> wrote:
> Thomas Higdon wrote:
>> I've written some code for decoding the video, but I'm a little
>> confused by what's on the wiki. I have a few questions:
>> 1. How does the palette work? Each frame apparently carries its own
>> palette part, which is PalColors * 3 bytes long, one byte for each RGB
>> color component. I'm pretty sure this is correct, because the audio
>> data starts where I expect it to. However, I'm not clear on the roles
>> of FirstColor1 and FirstColor2. What does it mean to "update PalColors
>> entries starting from FirstColor1 for odd and FirstColor2 for even
>> frames respectively"? Does the encoder carry some palette state that
>> is updated by each frame?
> I'm not the author of this wiki page, but if I understood correctly,
> the algorithm modifies the current
> palette in the following way:
> Suppose that PalColors == 10, FirstColor1 == 3 and FirstColor2 == 20.
> The first frame will then change the colors in the palette from index
> 3 to 13. The second frame will change from index 20 to 30.
> And then the third will, as the first, change from 3 to 13. The forth
> as an "even" frame, will update like the second and so on...

Ok, this makes some sense. The values I see in the sample videos are
PalColor = 120, FirstColor1 = 16, and FirstColor2 = 136. So frame 1
would update palette values 16 - 135 with the information contained in
that frame. At this point, values 0-15 and 136 - 255 are undefined,
meaning that an attempt to index one of those values in that frame
would be an error, I would assume. Frame 2 updates values 136-255. At
this point, only 0-9 is undefined, and would remain undefined for the
entirety of the video stream, meaning a byte of 0-9 would be an error.
I can buy this, though.

>> 3. Does the decoding proceed from top-to-bottom and left-to-right?.
> Probably yes. This is the simplest question to settle, it is easy to
> fix an image that is just flipped.
>> That is, when I look at the first tag in some frame's video data, and
>> consume the next byte to see what color to paint, am I on the upper
>> left macroblock at that point? Does the decoding proceed to the next
>> block to the right after the first is painted? I ask this because in
>> the "copy previous block" part of the algorithm, all of the possible
>> offsets have negative numbers, and would seem to refer to
>> already-painted macroblocks if things are decoded top-to-bottom,
>> left-to-right. Am I missing something?
> It is pretty possible that the decoder just use data from the previous
> frame if it wasn't yet painted.
> Since this is a FMV game codec, it could be that the original decoder
> just fetched whatever was in the video buffer at that position.

Thanks, I understand this now. I was thinking about it in a wrong way.

More information about the ffmpeg-devel mailing list