[FFmpeg-devel] FRAPS skip frame handling

[Michael Niedermayer]

On Sun, Jan 22, 2012 at 11:05:40AM +0100, Reimar Döffinger wrote:
> On Sun, Jan 22, 2012 at 07:24:47AM +0100, Michael Niedermayer wrote:
> > On Sat, Jan 21, 2012 at 08:16:45PM +0100, Reimar Döffinger wrote:
> > > On Sat, Jan 21, 2012 at 03:33:16PM +0100, Michael Niedermayer wrote:
> > > > On Sat, Jan 21, 2012 at 10:25:10AM +0100, Reimar Döffinger wrote:
> > > > > Hello,
> > > > > the FRAPS decoder seems to use reget_buffer for the single purpose of
> > > > > skip frame handling.
> > > > > This seems wasteful to me, isn't there some simpler way API-wise to
> > > > > indicate "no change"/shouldn't just returning 0 work just as well?
> > > > > One other reason to want to change it is because this seems like the
> > > > > only thing making it possibly non-trivial (though not difficult I guess)
> > > > > to make the decoder frame-multithreaded.
> > > > 
> > > > set data_size to 0 return buf_size
> > > > h263dec.c does it too
> > > 
> > > That does not seem to work, breaks the time stamps:
> > 
> > hmm, what timestamps go into the decoder and what comes out ?
> 
> The packet timestamps start at 0 and increment by 1.
> The time stamps when they arrive then at the decoder are broken though,
> 0 appears twice:
> pts: 0
> pts: 0
> pts: 33333
> pts: 66667
> pts: 100000
> pts: 133333
> pts: 166667
> pts: 200000
> pts: 233333
> pts: 266667
> pts: 300000
> pts: 333333
> I have no clue which is supposed to be the outgoing time stamp.
> I tried setting the frame pts to the incoming packet's but that had
> no effect at all (is it even used anymore??).
> Setting pkt_pts and/or pkt_dts did not change the slightest thing
> either.
> The time stamps coming out of guess_correct_pts are 0 and 166667.
> As are the values from get_sync_ipts.
> In do_video_out the input pts is first 0 then 5.000010.
> "duration" has a value of 5.000010.
> sync_opts is first 0 then 5.
> Same for big_picture.pts.
> However enc->coded_frame->pts stays at 0 and so does pkt.pts.
> The packet arrives that way in av_interleaved_write_frame,
> both times dts is AV_NOPTS_VALUE, pts 0.
> compute_pkt_fields2 fixes it then up with
> //XXX/FIXME this is a temporary hack until all encoders output pts
> and since it does not have enough information gets it wrong.
> The real WTF is that this hack is run without printing the slightest
> message. Would have saved me about an hour time if someone had
> simply made that hack say that the encoder is broken.

Is this a regression ?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120122/2511abd7/attachment.asc>