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

Michael Niedermayer michaelni
Sat Apr 7 13:28:58 CEST 2007


Hi

On Fri, Apr 06, 2007 at 10:41:35PM -0700, Nicholas T wrote:
[...]
> * I removed this code, but if it does turn on some optimization, I can
> put it back
> BethsoftvidContext * vid = avctx->priv_data;
> vid->frame.reference = 1;
>    vid->frame.buffer_hints = FF_BUFFER_HINTS_VALID |
> FF_BUFFER_HINTS_PRESERVE | FF_BUFFER_HINTS_REUSABLE;

yes please put these back


>    vid->frame.data[0] = NULL;

this was wrong


> * removed audio pts, appears to be unneeded. Audio delay is calculated
> by soundblaster dac as described on specification page, appears to be
> working for dagvid.
> * I think this is close to being a usable patch :) If anyone could
> find some skynet
> 
> 
> On 4/5/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> >just repost any questions i missed
> 
> I noticed that when I click the window in ffplay, it says "error
> while seeking." This happens with other sample files as well...with a
> segafilm sample file, like mine, it freezes on the current frame; with
> a wmv sample file, it usually keeps playing, but sometimes freezes
> near the end. Is it supposed to pause the video? the wmv file did
> successfully seek to the beginning when I pressed the left arrow key.

clicking on the window is supposed to seek not pause


[...]
> >i wouldnt call
> >if(linesize_sign * (line_start + xoffset + length +
> >   ((xoffset + length) / avctx->width) * wrap_to_next_line - frame_end) > 
> >   0) { return -1; }
> >
> >"slightly more"
> >
> >also your divison-multiply based check is executed per byte while mine is
> >just executed once per line
> that checks to make sure it doesn't run off the buffer, I don't think
> your code does that. By the time you add these features, it will
> probably be comparable length. Suppose some other demuxer feeds it bad
> data and doesn't do that check (mine does)...

my code does check for the end of buffer:
if(dst == picture_end)
    goto end;

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)


[...]
> >hmm, a 0 byte terminates the whole ...
> >do 0 bytes also occure in the middle of a packet? that is would a simple
> >copy all until the first 0 byte code work? this where alot simpler if it
> >would work ...
> no, because any data following a RLE num_bytes could be zero (zero
> index in the palette), or any non-RLE sequence could contain a zero.

i know that, my question was if such 0 index actually occurs


[...]
> +static int bethsoftvid_decode_frame(AVCodecContext *avctx,
> +                              void *data, int *data_size,
> +                              uint8_t *buf, int buf_size)
> +{
> +    BethsoftvidContext * vid = avctx->priv_data;
> +    char block_type;

> +    uint8_t * destination = vid->frame.data[0];
> +    uint8_t * frame_end = vid->frame.data[0] + vid->frame.linesize[0] * avctx->height;

wrong, these are not initalized before (re)get_buffer()


> Index: libavcodec/bethsoftvideo.h
> ===================================================================
> --- libavcodec/bethsoftvideo.h	(revision 0)
> +++ libavcodec/bethsoftvideo.h	(revision 0)
> @@ -0,0 +1,16 @@
> +#define VID_PALETTE_NUMCOLORS 256
> +
> +enum BethsoftVidBlockType
> +{
> +    PALETTE_BLOCK = 0x02,
> +
> +    FIRST_AUDIO_BLOCK = 0x7c,
> +    AUDIO_BLOCK = 0x7d,
> +
> +    VIDEO_FULL_FRAME_BLOCK = 0x03,
> +    VIDEO_DIFFERENCE_FRAME_BLOCK = 0x01,
> +    /// difference frames with a y-offset
> +    VIDEO_OFFSET_DIFFERENCE_FRAME_BLOCK = 0x04,
> +
> +    FINISHED_BLOCK = 0x14,

these could be vertically aligned


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- 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/20070407/0782f49b/attachment.pgp>



More information about the ffmpeg-devel mailing list