2009/8/13 Adam Dershowitz <[email protected]>:
> Any suggestions would be appreciated.  For example is there any way to force
> it to attempt to do real time decoding?  Or to flush out the buffer after
> each read so that the next decode would get the next frame that came in?

I'm not fully qualified to answer but I'll have a go at making a
couple of suggestions!

Firstly you need to be careful because you can't throw away random
p-frames because each p-frame could refer to the next one (or more
than one I think). If you show a p-frame, then miss one, then display
the next one, you'll get errors from ffmpeg and the video will almost
certainly distort  You can only throw frames away if you are prepared
to wait until the next IDR frame comes since an IDR frame is a full
picture (again *I think!*) and it doesn't refer to any other frames.

So maybe you could look at the ffmpeg source code and find the
variable that holds the number of buffered frames, if it goes above a
certain level, you probably need to throw away all frames until you
hit the next IDR frame, then you can start playing normally again.

If you have control of the encoding settings for the video source, you
could reduce the GOP size - the frequency of IDR frames. E.g. a GOP
size of 10 would normally mean 1 IDR frame followed by 9 p-frames. If
you're dropping around 2 p-frames per GOP, reducing the GOP by half
would probably improve things. Since an IDR is a full picture and
p-frames are "sub-pictures" it probably takes longer to decode.

Identifying IDR frames is another matter - basically look for "0x0 0x0
0x0 0x1 0x67...moredata" then "0x0 0x0 0x0 0x1 0x68... moredata", then
"0x0 0x0 0x0 0x1 0x65...moredata", I can't really type out much more!

As I said, I'm not expert but I know a bit, so the above might not be
totally accurate but I hope it helps.

Chris.
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user

Reply via email to