@somby
Forgot to tell You:
To see Stream-Starttimes and -Durations (and other StreamInfos), You may also implement
'av_dump_format()' in Your Code or use FFmpeg's
'ffprobe.exe':
https://www.ffmpeg.org/ffprobe.htmlThe biggest problem is to seek within a file.
That's, what I tried to tell You above ("it's getting even more complex, if You start Adding Features"):
Reading an AV-Stream is easy. Seeking synchronized(!) is a bit more complicated.
If You want to do all of this fast and accurate, it's even more complicated.
But it's getting really interesting, when You start Adding PlayerFeatures.
If I don't flush all buffers...If I flush all buffers after seeking
Here's another Dranger-like FFPlay-Code (not the newest one, but the BasicStructure is the same):
https://github.com/mpenkov/ffmpeg-tutorial or take the File in the Attachment 'ffmpeg-tutorial-master.zip'.
Ffplay has same problems, you can find it in documentation of ffplay...see "Seek with -ss pos".
This Part of the FFPlay-Documentation explains the Use of the ss-Commandline-Argument, that
sets an optional
StartPosition. In this Context, the Doc mentions, that
"in most formats it is not possible to seek exactly" and that "ffplay will seek to the nearest seek point".
So far, so true, but:
1. In FFPlay, these Problems are solved by Code to keep the Tolerance as small as possible,
2. In FFPlay, the "Seek with -ss pos" is other than Seeking in the running Stream (see below).
3. The Seek itself has an Inaccuracy of only some
MilliSeconds.
(Suppose, max. the Half of the Pts-Diff between two Keyframes.)
4. The Precision of the Seek depends on
Your Code:
Elder Versions of 'ffplay.c' and the current Version of 'FFPlay4Laz' use
'av_seek_frame()', that
"simply" seeks to the
Keyframe at a Timestamp.
Newer Versions of 'ffplay.c' and You use
'avformat_seek_file()', that
seeks to a
Timestamp(ts) within a given Range (...; min_ts, ts, max_ts: Int64; ...), whereat
the Seek-Mode and -Precision depend on that Range and some Flags.
ad SeekRange:
I don't think, that [-9223372036854775808..9223372036854775807] is a practical Choice.
'ffplay.c' uses that Range only to seek to a StartPosition; for the Range when Seeking in the Stream, see:
'ffplay.c' -> 'read_thread()' -> "int64_t seek_min" and "int64_t seek_max".
ad Flags:
You use 'AVSEEK_FLAG_ANY' (= "seek to any frame, even non key-frames"); 'ffplay.c' uses 'AVSEEK_FLAG_BYTE' to seek in Bytes.
-> If I got You right, You're currently Seeking to any FrameType within any Range.
In the Attachment
some Pics to demonstrate the Precision, that I achieve with 'av_seek_frame()'
with several MRL-Formats, when 'Starting paused, at 10,000 Sec.' and 'Stepping paused +/- 3Sec., +/- 30Sec. +/- 3Min.':
'SeekAudio.7z' and 'SeekVideo.7z'The shown Start- and EndTimes are the synchronized MRL-Positions before and after Seeking:
Seek-StartTime -> SeekStep -> Seek-EndTime -> Diff between Seek-EndTime and SeekTarget.
(The MRL-Position is, what the User would see as the "current PlayerPosition".)
Note:With Videos, the Differences to the SeekTarget seem to be very big. This is due to the Code, that
stops the Seek in a paused MRL: It's stopped, when the corresponding VideoImage is displayed - this may last a bit.
(-> some better Code is projected.)
Of course, the Precision of the Seek in the Stream itself is much higher.
it is impossible to solute all the problems.
Which one ?
I think the player is working good anough...
I never doubted that. It's all a Question of what You want.
It's like the Difference between a Watch and a Chronometer, or between SDL-Audio and Portaudio+ASIO.
Recent
