[FFmpeg-devel] Seek problem with ffmpeg-mt

Thomas Worth dev
Sun Feb 27 10:12:47 CET 2011


I am trying to implement some seek code using ffmpeg-mt, but am
noticing a strange problem. Perhaps I am going about this the wrong
way, which is why I want to mention it publicly. If this is obviously
wrong, some guidance would be greatly appreciated!

Using a 23.976 fps MP4 file containing an H.264 video stream for the
test, I am trying to seek to a specific frame. The issue is that PTS
values returned do not match the timestamps passed to av_seek_frame().
Now, let me just say this works 100% perfectly with normal ffmpeg,
it's only ffmpeg-mt that exhibits the problem.

Here is an example:

for(;;){
	av_read_frame(formatCtx, &packet);
	if(packet.stream_index == videoStream){
			
		avcodec_decode_video2(codecCtx, frameIn, &frameFinished, &packet);
		if(frameFinished){
				
			fprintf(stderr,"pts:%05d seekpos:%05d\n",packet.pts,seekpos);
		}
	}
}

This will print out all the pts values for each frame of the video.
This works ok with both ffmpeg and ffmpeg-mt, as expected. I get
output like this:

pts:00000 seekpos:00000
pts:01001 seekpos:00000
pts:02002 seekpos:00000
pts:03003 seekpos:00000
pts:04004 seekpos:00000
pts:05005 seekpos:00000
pts:06006 seekpos:00000
pts:07007 seekpos:00000
pts:08008 seekpos:00000
etc.

This is all fine. seekpos is of course 0, because I am just looping
through the video normally with no seeking. Now, if I try to implement
seeking using the exact same PTS values, I get this:

//seek function
av_seek_frame(formatCtx, videoStream, seekpos, AVSEEK_FLAG_ANY);

pts:00000 seekpos:00000
pts:02002 seekpos:01001
pts:02002 seekpos:02002
pts:03003 seekpos:03003
pts:04004 seekpos:04004
pts:05005 seekpos:05005
pts:06006 seekpos:06006
pts:07007 seekpos:07007
pts:08008 seekpos:08008
pts:09009 seekpos:09009
pts:10010 seekpos:10010
pts:11011 seekpos:11011
pts:12012 seekpos:12012
pts:14014 seekpos:13013
pts:14014 seekpos:14014
pts:15015 seekpos:15015
pts:16016 seekpos:16016
pts:17017 seekpos:17017
pts:18018 seekpos:18018
pts:19019 seekpos:19019
pts:20020 seekpos:20020
pts:21021 seekpos:21021
pts:22022 seekpos:22022
pts:23023 seekpos:23023
pts:24024 seekpos:24024
pts:26026 seekpos:25025
pts:26026 seekpos:26026
pts:27027 seekpos:27027
pts:28028 seekpos:28028
pts:29029 seekpos:29029
pts:30030 seekpos:30030

Notice how frame 1 (starting at 0) is skipped and frame 2 is repeated
twice. The same thing happens at frame 13 and frame 25, and so on for
the duration of the stream. The error is consistent and occurs every
12 frames.

I know with ffmpeg-mt there is a decode delay which is equal to the
number of threads specified in the codec context. I have already
accounted for this, and even so this shouldn't affect seeking as a
whole, only the first few frames returned. As you can see, I am
supplying seek values that are identical to the pts values returned
when seeking is not performed. Again, this works perfectly with normal
ffmpeg and I would just stick with it except for that ffmpeg-mt offers
much faster decoding on a multi-core machine.



More information about the ffmpeg-devel mailing list