[mythtv] RE: [mythtv-commits] mythtv commit: r7000 by danielk

[Anduin Withers]

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: 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
> 
> 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.
> 
> 
>