[XviD-devel] [BUG] BFrame encoder doesn't force intra for 1st frame

[Michael Militzer]

----- Original Message -----
From: "peter ross" <suxen_drol@hotmail.com>
To: <xvid-devel@xvid.org>
Sent: Monday, August 05, 2002 4:15 AM
Subject: Re: [XviD-devel] [BUG] BFrame encoder doesn't force intra for 1st
frame


> >From: "Michael Militzer" <michael@xvid.org>
> >Reply-To: xvid-devel@xvid.org
> >To: <xvid-devel@xvid.org>
> >Subject: Re: [XviD-devel] [BUG] BFrame encoder doesn't force intra for
1st
> >frame
> >Date: Mon, 5 Aug 2002 01:37:05 +0200
> >
> >Hi,
> >
> > > > I get those results when using either divx5 bvop compatibility or
> >plain
> > > > "xvid style". I'm glad that someone finally confirmed that problem.
> > > > For me, the xvid decoder crashes on bframes (even if I #define
> > > > #BFRAME_DEC), either the VFW in vdub and the DShow in WMP.
> > > > Interesting is that gruel could see that the files produced in
windows
> > > > encoder are wrong (shows the same there), but if encoding in linux
> > > > everything is fine.
> > >
> > > strange. Especially because for me here the encoded files seem not
> >broken,
> > > DivX5 and ffdshow can play them from the very beginning. So I'd rather
> > > suppose that something in the decoder part isn't perfect - but we'll
> >see...
> >
> >I just commited a fix for the windows b-frame problems, at least for me
> >everything works fine now.
> >As supposed the unprocessed but queued frames caused the problem - I
solved
> >this problem by writing N_VOPs to the bitstream while the queue is being
> >filled. Sure this is not the best solution because a delay is introduced
> >even if we'd use .MP4 file format, but as long as the API doesn't support
> >returning a status for every frame like processed/queued, there's nothing
> >we
> >can do about it.
> >
> >btw: before my changes there was a BitstreamPutBits(&bs, 0x7f, 8);
> >(encoder.c, l. 826) while the queue was being filled. I have to admit
that
> >I
> >don't really understand what this should do. Could the original author
> >(pete?) explain it to me, please?
> >
>
> when virtualdub sees a 1-byte frame containing 0x7f it will ignore the
> output frame. (but only when the fourcc=DX50)

Ah, I see. But that's not really a common solution, right? Is the current
N_VOP solution ok for now?


Michael