[Ffmpeg-devel] Re: Bethsoft VID demuxer and decoder

[Nicholas T]

Hi,

On 4/7/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> yes please put these back
done

> >    vid->frame.data[0] = NULL;
> this was wrong
I think other codecs had it to ensure that the codec close function
wouldn't try to free a buffer with no data in it. Just out of
curiosity, why is this wrong? because frame data is not initialized
yet, or it is just unneeded

> clicking on the window is supposed to seek not pause
okay, so, what do I do, or should I ignore this...bethsoftvid
obviously isn't the greatest format for seeking, as the block sizes
aren't known...

> my code does check for the end of buffer:
> if(dst == picture_end)
>     goto end;
oh okay, I get it, very nice.

> and its of course not possible that the end could have been reached
> if remaining>0 your checks are much more complex than needed
> one thing which you should check though is that the initial pointer
> before the loop is entered is valid (VIDEO_OFFSET_DIFFERENCE_FRAME_BLOCK
> frame can move that to pretty much arbitrary positions)
Okay, I did this in a pretty simple way, hopefully it's valid.
case VIDEO_YOFFSET_DIFFERENCE_FRAME_BLOCK:
            yoffset = bytestream_get_le16(&buf);
            if(yoffset > avctx->height) { return -1; }
            destination += vid->frame.linesize[0] * yoffset;

> i know that, my question was if such 0 index actually occurs
from a hex dump it appears it does.

> wrong, these are not initalized before (re)get_buffer()
sorry. I can assume linesize doesn't change though, right?

> these could be vertically aligned
okay

Nicholas

-- 
http://ntung.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bethsoft.diff
Type: text/x-patch
Size: 18254 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070407/38c50a15/attachment.bin>