[mythtv] [PATCH] Partial fix for mythtranscode segfault
ou401cru02 at sneakemail.com
Tue Dec 2 13:40:06 EST 2003
On Tue, 02 Dec 2003 16:37:39 +0100, "Kenneth Aafl°y" said:
> On Tue, 2003-12-02 at 15:41, Geoffrey Hausheer wrote:
> > On Tue, 2 Dec 2003 00:31:59 -0500, "Isaac Richards" said:
> > > On Monday 01 December 2003 05:59 pm, Geoffrey Hausheer wrote:
> > > > The best option I can think of is to not clear lastvpts on a
> > > > fast-forward, but that may cause some other issues, and i'm not familliar
> > > > enough with the code to know what they are. Can someone pick this up and
> > > > run with it? If not, the patch I posted will work fine for the
> > > > transcoder, but I'm not sure what the ramifications would be to other
> > > > video consumers.
> > >
> > > Hmm.. _could_ try to generate a dummy value, based on the previous value
> > > and
> > > how far the seek was.. Rewinding would need something similar, I'd
> > > think.
> > >
> > Need to be careful, as we need to be monotonically increasing. So if we
> > guess to far, we don't solve the problem.
> While looking at avformatdecoder.cpp:
> There is a lock around avcodec_decode_video, but not around
> lastapts/temppts is calculated, shouldn't pkt->pts be used if available?
> If the stream has b-frames, every non-b-frame will receive the previous
> value of a non-b-frame?
> long long temppts = pts;
> if (context->has_b_frames && mpa_pic.pict_type !=
> temppts = video_last_P_pts;
> video_last_P_pts = pts;
> if (temppts != 0)
> lastvpts = temppts;
> temppts = lastvpts;
You may be right that we can use the audio frame timecodes, but note that
lastvpts gets incremented by 1000/fps each frame, so each video frame is
currently gauranteed to get a monotonically increasing value (unless
lastvpts gets reset to 0 as happens here)
More information about the mythtv-dev