[Ffmpeg-devel] [PATCH] C93 demuxer and decoder (GSoC qualification task)

[Michael Niedermayer]

Hi

On Mon, Apr 02, 2007 at 04:46:55PM +0300, Anssi Hannula wrote:
[...]
> > iam not sure if the double reget_buffer() is completely safe, normally
> > id just call it on the frame which is changed and output ...
> 
> The intention is to write the new frame on top of the frame from two
> frames ago, as explained in the wiki:
> 
> Wiki note about C93_4X4_FROM_CURR  = 0x07
> "Note, that due to doublebuffering this can reuse of blocks painted two
> frames ago as well as already processed blocks of the current frame."
> 
> Wiki note about C93_NOOP           = 0x0E
> "Note that, due to the double buffering scheme used in the original
> decoder, this has the implicit effect of rendering the 8x8 block decoded
> two frames ago."
> 
> 
> Is there some easier or more correct way to do that instead of two
> reget_buffers?

well one reget_buffer() ... for the frame which you output, the second is
simply not needed, the frame cant disappear before release_buffer()

an alterntive is to use get_buffer() to get a new buffer, and copy the
blocks which are needed from 2 frames ago and at the end release_buffer()
the 2 frames ago frame this might or might not be slower depending on
the user applications


[...]
> > 
> >> +        }
> > 
> > changing the old picture is not safe it could be just drawn to the screen
> > by the user application in another thread
> 
> So I should instead memcpy the palette from oldpic to newpic, to ensure
> the new palette gets applied in the other one of our AVFrames as well?

yes


[...]
> > 
> > [...]
> >> +    location = url_ftell(pb);
> >> +    if (br->index * 2048 + c93->current_frame * 4 > location) {
> >> +        c93->current_frame = 0;
> >> +        c93->decode_audio = -1;
> >> +        while (c93->current_block > 0 && br->index * 2048 > location) {
> >> +            c93->current_block--;
> >> +            br--;
> >> +        }
> >> +    }
> > 
> > what does this do?
> 
> If the file was seeked backwards (by user), this would cause
> current_block to be updated appropriately instead of just seeking
> forward back to where we were. But as seeking is not implemented anyway,
> I guess this can be removed...

the user shouldnt call raw seek stuff on the files behind lav* back ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070402/56b85d64/attachment.pgp>