[FFmpeg-user] ffprobe duration analysis and -analyzeduration and -probesize

[Robert Krüger]

Hi,


thanks for the quick response.

On Tue, Jul 15, 2014 at 6:54 PM, Moritz Barsnick <barsnick at gmx.net> wrote:
> Hi Robert,
>
> On Tue, Jul 15, 2014 at 17:09:32 +0200, Robert Krüger wrote:
>
>> Now the command line options -analyzeduration and
>> -probesize exist and so I naively thought, if I just specified them
>> large enough so the entire file is parsed, durations must be exact
>> but that does not seem to be the case (I compared the values to the
>> ones obtained by adding up all packet durations of a given stream and
>> those make more sense).
>>
>> Where is my mistake?
>
> I'm guessing here, as I don't know how the duration is determined for
> this specific type of container and codec. But I assume that those two
> options don't change the way it's determined, they only change two
> parameters. So if ffmpeg happens to do something like checking file
> headers or estimating from the initial frame and bit rates, this may
> not change.

If someone could confirm this, this would answer my question.

>
> If you're going to have ffmpeg analyze the whole file anyway, there are
> several other ways to do this:
> * Have ffprobe output data for each and every frame, and then count
> those frames.

I know that alternative and I have a solution doing that via API up
and running. I was just looking for a way to simply make ffmpeg (or
rather the api) do that automatically for me to avoid that but if
there is no other way, I will live with that.

>
> * Have ffmpeg operate on the complete file, and grab its results:
> $ ffmpeg -i VTS_03_1.VOB -an -sn -f null -
> [...]
> Input #0, mpeg, from 'VTS_03_1.VOB':
>   Duration: 00:00:31.55, start: 0.280000, bitrate: 8357 kb/s
> [...]
> frame=  791 fps=352 q=0.0 Lsize=N/A time=00:00:31.64 bitrate=N/A
>
> (I think I have seen a solution on this list to parse the latter.)
>
> Note the final "frame=" output. I don't know whether adding "-c
> copy", which is noticably faster, always definitely produces the same
> results.

Since the output of this is not really "api", the ffprobe variant
would be safer but everyone has to make their own call regarding the
risk of having this text output change from one version to another.

Cheers,

Robert


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com