[mythtv-commits] mythtv commit: r6990 - in trunk/mythtv/libs by danielk

mythtv at cvs.mythtv.org mythtv at cvs.mythtv.org
Thu Aug 4 21:21:52 UTC 2005


      Author: danielk
        Date: 2005-08-04 21:21:51 +0000 (Thu, 04 Aug 2005)
New Revision: 6990
   Changeset: http://cvs.mythtv.org/trac/changeset/6990

Modified:

   trunk/mythtv/libs/libavformat/avformat.h
   trunk/mythtv/libs/libavformat/mpegts.c
   trunk/mythtv/libs/libavformat/mpegts.h
   trunk/mythtv/libs/libavformat/utils.c
   trunk/mythtv/libs/libmythtv/avformatdecoder.cpp
   trunk/mythtv/libs/libmythtv/videobuffers.cpp

Log:

Partial fix for the mpeg-ts problem.

I've been using this locally for a couple days now,
so it should be fairly stable.

In mpegts.c/mpegts.h & utils.c/avformat.h there are three changes:
  1/ When the streams change, packets in the old streams are flushed.
  2/ All codecs are closed when streams change.
  3/ Streams are changed all at once after scanning the whole PMT.

#2 should fix some of the audio problems during channel changing.
#1, #2, #3 together seem to have solved the problem of ffmpeg writing
past the end of the audio buffer.

In avformatdecoder, there have been some adjustments for #2 above, plus
there is much more debug info.

In videobuffers.cpp, I've increased the safety below each allocated
buffer, this allocator is used by VideoOutputNull.cpp. I'll reduce
this again once I figure out the remaining mpegts problem, this
prevents a segfault when generating previews for a video with
multiple stream changes in the first few seconds of a video.

This doesn't completely solve the problem however, ffmpeg is no longer
writing past the end of audio buffers, but it is still writing past the
end of the video buffers. Worse it looks like it is doing this on the
stack. This is in AvFormatDecoder::GetFrame() and it makes the
backtraces a bit "interesting".

BTW A workaround to the remaining problem is to use XvMC...






More information about the mythtv-commits mailing list