[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