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

Nicholas T ntung
Wed Apr 4 20:39:25 CEST 2007


Sorry, forgot to attach diff.

On 4/4/07, Nicholas T <ntung at ntung.com> wrote:
> Hi,
>
>    Thanks for your responses.
>
>    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.
>
>    As for the audio, I tried setting the pts, but it made no
> difference. Am I supposed to give it some blank code if there is no
> more data? It happens that the audio matches up in all of the sample
> files without further adjustment, but I don't think this is assumed by
> the format specification.
>
> On 4/3/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> > if you dont have a lot of time now how do we know that you have a lot
> > of time for the actual SOC?
> Is this a rhetorical question? I will not be in school...if I get into
> SOC I will not be doing anything else.
>
> > > The heap is better for large
> > > allocations?
> >
> > yes
> done, though my memory allocation looks a bit clunky...maybe there's
> something I can simplify?
>
>
> if(vidbuf_nbytes + BUFFER_PADDING_SIZE > vidbuf_capacity)
> {
>     vidbuf_start = av_realloc(vidbuf_start, vidbuf_capacity +=
> BUFFER_PADDING_SIZE);
>     if(!vidbuf_start) { return AVERROR_NOMEM; }
> }
>
> > i dont know how i can be more specific than "overflowing multiplication"
> > integer overflow followed by writing to unallocated memory
> okay, Mr. Melanson explained this as well (thanks to both of you), I
> guess I wasn't thinking of malicious files...great point. Hopefully
> this patch will fix that.
>
> > > okay, all  linesizes < width  now fail, as that's rather meaningless.
> >
> > its not meaningless, the image can be flipped and data[0] can point to
> > the last line
> How is the image flipped? Is that for negative linesize? And for
> linesize less than the width, am I supposed to truncate lines?
>
> > AV_RB24()*4 does
> oh yeah...that was stupid, sorry.
>
> > it does have AVStream which has AVCodecContext which has width/height
> okay, now using s->streams[0]->codec->width, and height
>
> > i dont think doxygen supports comments before loops
> I know, but the comment is a different color in my editor and easier
> to see :) fixed
>
> > significantly too complex for a rle decoder
> Perhaps this is an illusion of my using comments and long variable
> names? If you look at Konstantine's Autodesk RLE decoder (aasc.c),
> it's 39 lines with a macro, whereas mine is 30 lines (not counting
> comments, whitespace, and lines with only a brace). Nothing against
> Konstantine...I'm sure that decoder has justification, but mine really
> isn't that complex. What would you suggest to simplify it? It's a bit
> of a pain dealing with the linesize and width.
>
> > whats that nested struct good for?
> it looked better in a struct when I had a lot of excess variables. I
> removed it now.
>
> > the demux context belongs into the demuxer
> > the decode context belongs into the decoder
> right, moved out of header file. Also removed excess avctx in codec context.
>
> > breaks ABI
> I should put bethsoftvid after thp? Thp was just added.
>
> > > +    BVID_DemuxContext *vid = (BVID_DemuxContext *)s->priv_data;     // permanent data outside of function
> >
> > useless cast
> fixed, though it's in almost all of the other codecs...do you want me
> to clean it up, along with empty functions (in another patch)? It
> probably wouldn't be too difficult with a regex.
>
> > why not use  get_le16(pb); ?
> fixed
>
> > why 16bit ?
> video delays are 16 bit, this is what you told me when you were
> explaining the timestamp, no? If the int16 overflows, the pts should
> continue to increment, not actually going to 0, right?
>
> > audio has no width/height
> fixed, sorry for the carelessness.
>
> > wrong indention
> fixed, though perhaps "inconsistent", not "wrong", it's a style preference.
>
> > SEEK_CUR
> thanks
>
> > you cannot allocate the packet after setting its fields
> fixed
>
> > whats that good for?
> changed to debug log
>
> Nicholas
>
> --
> http://ntung.com
>


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



More information about the ffmpeg-devel mailing list