Build is broken when building without XVMC. videoout_xv.cpp:40: error: 'void clear_xv_buffers(VideoBuffers&, int, int, int)' used but never defined
-- Anduin Withers > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:mythtv-commits- > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Monday, August 08, 2005 1:12 PM > To: [email protected] > Subject: [mythtv-commits] mythtv commit: r7000 by danielk > > Author: danielk > Date: 2005-08-08 17:11:32 +0000 (Mon, 08 Aug 2005) > New Revision: 7000 > Changeset: http://cvs.mythtv.org/trac/changeset/7000 > > Modified: > > trunk/mythtv/libs/libmythtv/NuppelVideoPlayer.cpp > trunk/mythtv/libs/libmythtv/avformatdecoder.cpp > trunk/mythtv/libs/libmythtv/avformatdecoder.h > trunk/mythtv/libs/libmythtv/tv_play.cpp > trunk/mythtv/libs/libmythtv/videobuffers.cpp > trunk/mythtv/libs/libmythtv/videoout_xv.cpp > > Log: > > Fun stuff concerning MPEG transport streams. > > Basically there are three important things: > 1/ Dimensions are now ALWAYS aligned to 16 pixels when using MPEG. > This was giving us the green bar in some cases when one changed > to a 1080i stream, while using XVideo output. > 2/ AvFormatDecoder has it's own Reset() which resets the mpegts > context (actually it closes and reopens it, same effect). > This prevents problems when you change channels and > the streams change, but the PMT doesn't change so > HandleStreamChange() is not called to deal with it. > 3/ HandleStreamChange() does a SeekReset() so that all old > packets are disgarded. > This prevents a number of ffmpeg problems from > getting in our way. > > No. 2 can theoretically fail which meant some error checking was > needed in NVP and TVPlay. > > There are a couple minor fixes in VideoOutputXV and VideoBuffers: > 4/ VideoBuffers no longer allocates alot of scratch space when > it allocates buffers. I've fixed the memory overwrite problem > so this is no longer needed. > 5/ VideoOutputXV now only frees and realloces buffers when > the resolution changes on an input change. > 6/ VideoOutputXV now clears the buffers to black on an input > change and when new buffers are allocated. This doesn't > prevent green screens completely, this can still happen > when an I frame is not the first frame when ffmpeg > restarts. Fixing that would require the same type of fix > in ffmpeg's mpegvideo.c > > > NOTE: > There is still a potential race condition with GetFrame() > between when pmt_cb() rewrites the streams list and when > HandleStreamChange() acquires the avcodeclock lock. But it > doesn't seem to happen in practice and sticking the locking > in ffmpeg's pmt_cb() is ugly. > > The proper way to handle this would be to not use a callback at > all but to add CODEC_TYPE_STREAM change stream and not do the > stream change until that was seen by GetFrame(). Then there > would be no need clear out old packets in HandleStreamChange(). > But this is a complex solution for another day. > > >
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
