[FFmpeg-devel] mutlithreading in ffmpeg?

[Reimar Döffinger]

On Tue, Mar 29, 2011 at 01:05:34PM -0700, Thomas Worth wrote:
> Also, I get the following error after seeking directly to a frame
> following a keyframe:
> 
> [h264 @ 0x100819400] Missing reference picture
> [h264 @ 0x100819400] decode_slice_header error
> 
> I get this error, but I STILL get a frame correctly with ffmpeg. With
> ffmpeg-mt, it skips it and returns the next frame instead:

That sounds like it just skips error concealment in that case.

> seekpos:00000|pts:00000|decode2 return val:4883|got_pic_ptr:328|is keyframe:1
> seekpos:01001|pts:01001|decode2 return val:0319|got_pic_ptr:000|is keyframe:0
> seekpos:01001|pts:02002|decode2 return val:0318|got_pic_ptr:328|is keyframe:0
> seekpos:02002|pts:02002|decode2 return val:0318|got_pic_ptr:328|is keyframe:0
> 
> Notice that on frame 2 (timestamp 1001), the return value from the
> decode function is 319, which is different from the next P frame,
> which is 318. Now of course we get 318 twice at PTS 2002 because
> ffmpeg-mt is returning the same frame twice, even though two different
> timestamps are specified.

I'm afraid you have a talent for writing explanations that confuse
me more than they help :-)
I'd say what happens is just that ffmpeg(-mt) in that case decides
to completely drop the frame instead of "making something up" via
error concealment. That is probably a bug in so far as it's not supposed
to do that, but if your code fails with this it is too brittle.

> > probably because theres 1 frame delay
> > if this changed over the ffmpeg-mt merge then we might have a bug in
> > there but 1 frame delay streams (without B frames) are rather common
> > practically all mpeg2 without b frames fall in this category
> >
> > can you confirm that the delay behavior changed?
> > if yes i need a reproduceable test case to look into it
> 
> Absolutely. I have attached a sample program and makefile, which
> should show the phenomenon. If you compile with normal ffmpeg
> libraries and then run a test, you will see that the PTS values
> returned are consistent with timestamp values passed to av_seek_frame.
> If you compile with ffmpeg-mt, you will see that there is a "delay"
> (i.e. error) even if you set threads to "1" and even if you compile
> without pthreads.

As said, ffmpeg-mt IMO is obsolete, have you tested with ffmpeg latest git?
Sorry I don't think I'll have time to test today at least.