[mythtv] RE: [mythtv-commits] mythtv commit: r7000 by danielk
awithers at anduin.com
Mon Aug 8 13:40:45 EDT 2005
Build is broken when building without XVMC.
videoout_xv.cpp:40: error: 'void clear_xv_buffers(VideoBuffers&, int, int,
int)' used but never defined
> -----Original Message-----
> From: mythtv-commits-bounces at mythtv.org [mailto:mythtv-commits-
> bounces at mythtv.org] On Behalf Of mythtv at cvs.mythtv.org
> Sent: Monday, August 08, 2005 1:12 PM
> To: mythtv-commits at mythtv.org
> 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
> 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
> 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.
More information about the mythtv-dev