@mercury
Hi mercury !
I'm delighted, to find finally somebody else, who's interested in FFmpeg-Stuff.

LibFFPlay is a simple C lib for video/audio playback...can use by any program language as normal C lib.
In other Words:
A C-DLL-File, that simply exports basic PlayerFunctions, and -Parameters from the original FFPlay-C-File.
In this pragmatic Way, of course, You don't have to bother too much with the FFPlay-SourceCode itself, and
You avoid messing around with PascalHeaders, that by Natur never can be really complete and up-to-Date, and
it's much easier to follow the latest FFmpeg-Updates.
So far, so good,
but: (Sorry, but now some "buts" are coming.)
> What's the Advantage of Your 'LibFFPlay', compared with:-
Acinerella: https://github.com/astoeckel/acinerella-
FFDec: http://sourceforge.net/projects/ffdec> ad 'FPS', shown in Your Screenshot:In Your Screenshot, there is a Series of whole-numbered (integer) Values from 23 to 25, called 'FPS'.
This 'FPS' is simply calculated by Counting up the 'BGRABitmaps', and then showing the Sums per Sec., see:
Unit 'LibFFplay', Line 427: "FPS += 1;", and Unit 'Unit1', Line 72: "TForm1.Timer1Timer".
Some might confuse this 'FPS' with FFmpeg's FPS, which is the 'Number of Frames in a STREAM per Sec.', whereat
EACH Stream in the AV-Stream may have DIFFERENT TotalAmounts of Frames, and FrameRates.
It's then up to the PlayerCode, to put all this Mess in Order. That's why progging a MediaPlayer is
much more complex, than progging an AudioPlayer, that only has to deal with ONE Stream: Audio.
Your 'FPS' rather represents an approximate 'Number of DISPLAYED VideoPictures per Sec.', after
having passed all the Bunch of Decoding, Syncing, and eventually Skipping VideoFrames.
> ad AudioData-Callback-Function:There isn't - As long as You don't add an AudioData-Callback, the Sound actually comes from
the FFPlay-C-File's SDL-Audio, and You (or eventual Users of 'LibFFPlay') can't implement any
own AudioCode (e.g. DSP), or add another Audio-Output (e.g. Portaudio).
> ad VideoData-Callback-Function 'Cb_display()':Currently Your VideoData-Callback is placed at a Position in the FFPlay-Code, where the PictureQueue (now called 'FrameQueue') is completely left out from the VideoSync-Process, see:

(Your modified) 'ffplay.c', Line 1815.
(I saw, that this Part is marked as "TODO", so I suppose, You'll fix that.)
Here's a simplified WorkFlow of, how 'ffplay.c' generates a synced VideoImage:
AV-Stream -> Read VideoFrames -> Video-PacketQueue -> Decode VideoPackets -> Sync VideoFrameIn-PTS ->
Scale to VideoFrameOut -> PictureQueue -> Fetch synced(!) VideoPicture -> Display (Puh!).
Your VideoData are fetched after 'Scale to VideoFrameOut' (= the VideoPicture), but to achieve a really
accurate VideoSync, 'ffplay.c' synchronizes the PTS of each completely decoded VideoFrame
ANDcalculates the Delay in Ms for each single VideoPicture, that shall be displayed.
=> The right Place to fetch VideoData would be at Line 971 of (Your modified) 'ffplay.c',
exactly where You commented out "SDL_DisplayYUVOverlay(vp->bmp, &rect);".
-> Why don't You put Your VideoData-Callback there ?
To demonstrate the PictureQueue-Sync at Work, You'll find in the Attachment a ScreenShot of
a typical Series of real Values for 'Current VideoPictures per Sec.', generated by my 'FFPlay4Laz'.
(
http://forum.lazarus.freepascal.org/index.php/topic,26666.0.html)
BTW:Please, mark the Changes, You've made
inside the original FFPlay-C-Code, to make
it easier for Others to differ between the original Code and Your Modifications.
If you can't see the attachment, maybe login is needed
To see the Attachment, Login IS needed.
Tip for You:You may use 'AV_TIME_BASE', instead of '/ 1000 / 1000'.
Tip for all the Others in this Forum:'LibFFplay\libffplay.cbp' is a
Code::
Blocks-
ProjectFile:
http://www.codeblocks.org.