danielk at cuymedia
Dec 26, 2005, 3:31 PM
Post #1 of 5
(751 views)
Permalink
|
|
Re: [mythtv-commits] Re: Ticket #868: [8350] breaks mpeg2 decoding during frame advance
|
|
On Mon, 2005-12-26 at 03:59 +0000, ijr wrote:
> #868: [8350] breaks mpeg2 decoding during frame advance
> When you call avcodec_flush_buffers, it doesn't just flush the buffers, it
> resets the entire decoder state, even parsing. This simply cannot be
> called after a seek, unless we're decoding a keyframe next.
I'll audit every Reset request in the NVP tomorrow and make sure it
makes sense.
> Part of the issue also could be the change to the 'skipframes' loop. For
> exact seeking, we need to actually decode those frames so it can
> successfully decode and display something in the middle of a gop, and that
> loop looks like it is no longer doing so.
This was the first thing I thought might be the problem. But while
it looks like it is a bug, it isn't causing this problem; the bug
bjm reported is present on a single frame FF right after a keyframe,
this loop isn't used in that case but we do add two frames to available
which avlib hasn't returned yet.
> The change to AVFD::Reset(bool, bool)'s call of SeekReset to flush frames
> is also likely wrong - that's called after what should be a seamless file
> change, so it certainly shouldn't be flushing the decoder.
I'll check this.
> I don't think the HandleStreamChange callback should be flushing out the
> video frames, either.
I think this is needed until I implement the seamless video frame
resize. The old frames need to be completely freed from libav use
so that new ones can be allocated of that are the right resolution
for the new streams. mpegts.c really needs to output another stream
which tells MythTV about new PMT's just after the last packet from
the old streams and before the first packet from a new streams.
Then we can get rid of the old buffers on a frame by frame basis
as we finish with them.
-- Daniel
|
