[FFmpeg-user] How to get he total number of frames

[Mark Filipak (ffmpeg)]

On 2021-03-11 18:37, Reino Wijnsma wrote:
> On 2021-03-09T20:43:21+0100, Mark Filipak (ffmpeg) <markfilipak at bog.us> wrote:
>> On 2021-03-09 03:58, Michael Koch wrote:
>>> These links might help:
>>> https://stackoverflow.com/questions/2017843/fetch-frame-count-with-ffmpeg
>>> https://superuser.com/questions/1512575/why-total-frame-count-is-different-in-ffmpeg-than-ffprobe
>>>
>>> Michael
>>
>> Those links are really hard to follow and it's fruitless to try to find what's there that works vs. what doesn't work.
>>
>>  From Ulf Zibis:
>> can one please tell me, how I can get the total number of frames of a video?
>>
>> Was Ulf's question actually answered? I think not.
> 
> How can you say that? These urls do exactly that. They offer a couple of solutions on how to get the total number of frames.
> What is so hard to follow?


Re, https://stackoverflow.com/questions/2017843/fetch-frame-count-with-ffmpeg.
I think this:
'ffmpeg -i input.mkv -map 0:v:0 -c copy -f null -'
does not report the number of frames for input.mkv. I think it reports the number of frames output 
by the default encoder. Based on much experimentation with sources that have frame numbers burned 
in, I don't trust this approach as ffmpeg often silently skips input frames at the beginning of 
streams -- I often see this [1] -- and ffmpeg doesn't always indicate dropped frames elsewhere -- I 
often see this. If the point is to absolutely know the number of input frames (perhaps to know 
whether ffmpeg is dropping any frames), I don't think this is the way to do it. I could be wrong 
because I'm so ignorant. But burned-in frame numbers don't lie.
:
[1] Specifically, videos copied from DVDs with 'drawtext...text=%{n}' but that show burned-in frame 
number beginning with '1' (or '2' or '3' ..).
Example:
Frame #s 1..3596 <=burned-in
@ 30/1.001fps <=confirmed
with 2:00.071 running time <= 3598.[516483..] to 3598.[5464..] actual frames
"frame= 3596 fps= 30 q=15.8 Lsize=   87555kB time=00:02:00.03 bitrate=5975.2kbits/s dup=0 drop=1 
speed=0.988x" <= last line of log
-- What is a person to believe?
:
This is confusing:
"This is a slow method. Because the whole file must be decoded --> you're using -c copy, so no 
decoding. – Gyan Jul 27 '18 at 5:00"

There's more, but I've probably made my point.

I think my second request to this list (after asking for the meanings of 'tbr', 'tbn', and 'tbc' and 
not getting anything definitive) was a request for command lines that are known to work. I was 
trying to figure out what the cryptic documentation was trying to 'say' -- CLI examples posted by 
people who are in trouble are not good examples. I was pretty brutally attacked for making such an 
outrageous request.

I've learned a lot since then, but of course with no place to put it, all that knowledge and unique 
perspective and experience is wasted.