[FFmpeg-devel] Request for comment: Tutorial

Stephen Dranger dranger
Fri May 25 04:31:11 CEST 2007

On 5/25/07, Scott Harper <orcein at gmail.com> wrote:
> On 2007/05/21, at 22:47, Stephen Dranger wrote:
> > I have written a rather lengthy ffmpeg tutorial that starts by going
> > over Martin Bohme's old tutorial, then proceeding to recreate
> > ffplay.c, teaching about how ffmpeg, SDL, and video in general works.
> >
> > Here's the link:
> > http://dranger.com/ffmpeg/ffmpeg.html
> Excellent tutorial!  That will be very helpful, especially the part
> where you explain the syncing elements.
> The problem I've had with writing a simple player using ffmpeg and
> SDL (I even added a progress-bar like in most media apps!) is
> detecting the END of the video...  I.E. making sure that it PLAYS the
> last frames, and doesn't try to read beyond the end incessantly,
> jumping forward to the end/last frame, noticing that the player is at
> the end and setting it pause playback and know that if you press
> "play" again it should seek to the beginning again and unpause from
> there...  I think part of the problem was that some of the different
> video files I was using might have had different ways of ending.
> Another problem might have been seeking to the end, where I had to
> get the last keyframe and built up (Mpeg4 videos, especially) to the
> last frame's timestamp.
> What I was doing was (and this was a few months ago when school was
> lighter and I could afford to be working on it) getting the ratio
> across the playback-bar thing when the user clicked it, then
> multiplying that ratio by the value represented in 'AVFormatContext-
>  >streams[videoStream]->duration', turing it into an integer, and
> seeking to there with AVSEEK_FLAG_BACKWARD, and then decoding/
> rendering frames in memory until I got to the projected frame...
> Perhaps this was the wrong way of going about it?
> The other problem I ran into was that I would decode frames up to the
> seeked-to video frame, but then the audio ratio was comnpletely
> different... like the video frame either changed to quickly or lasted
> noticably (to me) too long before changing... (I am syncing video-to-
> audio, and seeking by audio didn't work because then I missed key
> frames... (those are i-frames, right?)  Did I miss something in audio
> packets having multiple frames that allows me to more accurately
> determine where to begin my audio playback after random seeking?
> Anyway, that's my problem area, if you want to write about that. ^_^
> Also, how does seeking by Bytes work?  I saw in your end section how
> it said that was better than by frame number?
> Sorry for the long post, hope it was clear enough and on-topic enough
> to not get flames too badly. ^_^
> -- Scott

Well as far as seeking is concerned, you're usually going to want to
just seek like in the tutorial. av_seek_frame is going to seek to the
next key frame unless you set AVSEEK_FLAG_ANY. I do believe that
av_seek_frame is going to seek to the next key frame even if you
specify the audio stream in the call. Make sure you are clearing
avcodec's buffer and any internal buffers you might have when you
seek, too.

Your idea of taking the fractional value of "duration" is correct, I
think, but remember that that value is in AV_TIME_BASE units, and if
you pass av_seek_frame an audio or video stream, you need to rescale
that value first to be in that stream's units. I don't know that you
need to "seek frames up to the video frame", either. av_seek_frame
will take you to the location that you want right away. I'm not really
sure what's wrong with your player though; it could be a lot of

As far as seeking by bytes goes, check out ffplay.c. Basically, it
works like this: you get the actual current offset of the file, then
use the bit rate from AVFormatContext to figure out how many bytes you
want to skip ahead/behind. Then ffmpeg will go back that many bytes.
I'm not certain if seeking by bytes guarantees you will seek to a key
frame or not (from peeking at the source, it seems like you aren't
guaranteed that; I'm really not sure).

I don't think seeking by bytes is any better, and looking at the
mailing list, it looks like it is just preferable when using files
where the timestamps are discontinuous (like VOB). Here's the mailing
list discussion about why the feature was added to ffplay.c:


More information about the ffmpeg-devel mailing list