My fix was - as expected - simple as finding the correct variable to poll with ffprobe:
*'r_frame_rate' is "the lowest framerate with which all timestamps can be > represented accurately (it is the least common multiple of all framerates > in the stream)."* *'avg_frame_rate' is just that: total duration / total # of frames* Switching to 'avg_frame_rate' gets me the correct rate to calculate against - bing, bosh. VFR timing works as expected. --- But I am still trying to insinuate here that the console output of ffmpeg, in so much as I understand it, is just plain *INCORRECT*. The output stream in this instance is 'rawvideo.' There is no frame drop/duplication enabled or happening as far as I know -- and the frame count of the test I originally described in this thread supports that. The source footage is VFR with an average frame rate that calculates to 30.011923688394276fps. When I open a stream to ffmpeg, what I receive from the output stream is every single one of that source's frames. Literally nothing has changed from input to output in this operation to alter the frame base/rate or number of frames I will receive. (as far as I am aware) Despite the equity of INPUT and OUTPUT here, the output stream is loudly declaring itself 30fps. *Which it is not*. That's just not at all correct. And the value '30fps' is occupying the same position in the stream metadata where the source input frame rate was displayed. Which communicates clearly that on the input, this was 30.01fps -- but the output is now 30fps flat. A purely FALSE declaration that misled me into thinking that both 'r_frame_rate' and the actual output stream were converting VFR to the nearest standard timebase by some internal magic. Me, trusting the console output, resulted in a bug in my code and subsequent timing inaccuracies... because the console output is not correct. All that said... After glancing at some superuser threads it looks like this output stream frame rate is accurate / helpful in other circumstances. Like when altering the frame rate of the output with vsync declarations, or when full-on transcoding. And it wouldn't make any difference when you've got a CFR source at an industry-standard frame base. But in this use case of rawvideo output from a VFR source, that fps figure is nothing but a *wrong number* in an important place, misleading anyone who looks at it. Which, to my mind, makes it a bug that wants some error-trapping. Am I wrong? -Roninpawn On Tue, Mar 16, 2021 at 12:56 PM Carl Zwanzig <[email protected]> wrote: > On 3/15/2021 6:51 PM, roninpawn wrote: > > I develop a Python application used to conduct official timing for > > speedrunning leaderboards based on automated video analysis. > > Instead of relying on output frame rate, have you considered using the > Presentation Time Stamps (PTS) of the input? Those more accurately direct > when a frame should be displayed (presented) so the timing ought to be > more > accurate. > > (There was much discussion about PTS on this list recently.) > > z! > _______________________________________________ > ffmpeg-user mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". -- Roninpawn on YouTube (http://www.youtube.com/user/roninpawn <http://www.youtube.com/user/roninpawn>) _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
