[FFmpeg-devel] FRAPS skip frame handling

[Reimar Döffinger]

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.