[mythtv-commits] mythtv commit: r7000 by danielk

mythtv at cvs.mythtv.org mythtv at cvs.mythtv.org
Mon Aug 8 17:11:33 UTC 2005


      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.






More information about the mythtv-commits mailing list