[MPlayer-dev-eng] [PATCH] ve_lavc delayed frames

Ivan Kalvachev ivan at cacad.com
Mon Nov 8 06:03:44 CET 2004


On Wed, 28 Jul 2004 13:31:50 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> Hi
> 
> On Wednesday 28 July 2004 12:47, Loren Merritt wrote:
> > On Wed, 28 Jul 2004, Michael Niedermayer wrote:
> > > On Tuesday 27 July 2004 00:49, Loren Merritt wrote:
> > > > When encoding to lavc with b-frames, mencoder emits some dummy frames
> > > > at the beginning of the output video (because lavc hasn't returned any
> > > > compressed frames yet). This causes A-V desync, and (the case that I
> > > > first noticed) messes with timestamps in a variable-framerate video.
> > > >
> > > > This patch supresses the dummy frames.
> > >
> > > why do u use lavc_venc_context->coded_frame->pict_type instead of
> > > outsize?
> >
> > I'm pretty sure frames aren't supposed to be of type '?', while I saw no
> > particular reason that size 0 should be invalid. Maybe I'm wrong, though.
> see output_example.c in ffmpeg cvs, but u are right pict_type may work too, 
> its just not exactly supposed to be used for this, it could be uninitalzed or 
> coded_frame could be NULL, as no frame has been written yet theres no 
> gurantee that coded_frame contains meaningfull values ...
> 

Whatever pict_type or out_size is better, this should be fixed.
Az I have commited support for flushing frames at the end of encoding
(required for xvid4), so ve_lavc could be fixed in the right way.

Loren I have strange feeling that you are mplayer developer, so you can do it...

Wish You Best
   Ivan Kalvachev
  iive




More information about the MPlayer-dev-eng mailing list