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
