[FFmpeg-user] Get exact duration of an mpeg1 file

[Robert Krüger]

On Tue, Dec 18, 2018 at 11:40 PM Carl Eugen Hoyos <ceffmpeg at gmail.com>
wrote:

> 2018-12-18 21:49 GMT+01:00, Robert Krüger <krueger at lesspain.software>:
> > On Fri, Dec 14, 2018 at 5:28 PM Carl Eugen Hoyos <ceffmpeg at gmail.com>
> wrote:
> >
> >> 2018-12-14 17:19 GMT+01:00, Robert Krüger <krueger at lesspain.software>:
> >> > On Fri, Dec 14, 2018 at 3:03 AM Carl Eugen Hoyos <ceffmpeg at gmail.com>
> >> wrote:
> >> >
> >> >> 2018-12-13 17:10 GMT+01:00, Robert Krüger <krueger at lesspain.software
> >:
> >> >>
> >> >> > is there a way to get the exact duration of a raw mpeg1 file using
> >> >> > the
> >> >> > ffmpeg command line? For testing I created a 30 minute test file
> >> >> > using
> >> >> > ffmpeg (using -c:v mpeg1video -f mpeg1video), then verified the
> >> duration
> >> >> > using VLC and mediainfo and it is indeed exactly 30 minutes long
> but
> >> >> > ffmpeg -i shows the file's duration as 00:00:04.98 after displaying
> >> this
> >> >> > warning:
> >> >> >
> >> >> > [mpegvideo @ 0x7fe212806000] Estimating duration from bitrate, this
> >> >> > may be inaccurate
> >> >> >
> >> >> > Are there command line parameters to make it compute the exact
> >> >> > size or is this a design or implementation limitation?
> >> >>
> >> >> Just the mpeg specification;-)
> >> >>
> >> > Yes, sure, having to count packets/frames is unavoidable for some
> >> formats.
> >> > My question is rather whether ffmpeg's (or rather libavformat's)
> >> > duration
> >> > computation code can be made to do this internally without these
> >> > workarounds.
> >> >
> >> >> $ ffmpeg -i input -c copy -f null -
> >> >
> >> > Thanks for the command line.
> >> >
> >> > Just a comparison: This approach gives me the duration information
> for a
> >> > 180 minute file in 1.8 seconds while mediainfo does it in 0.25 seconds
> >>
> >> (Does your input have timestamp discontinuities? You could try to
> >> concatenate a few parts - or cut away something - from the input file.)
> >>
> >
> > Very unlikely since I generated the sample using an ffmpeg command line
> > using testsrc.
>
> But you should test with a file with timestamp discontinuities to
> test your claim that it can be done faster than with FFmpeg.
>

I begin to understand. You are saying that it is possible that Mediainfo is
more or less "cheating" to obtain its results. Interesting. For my use
cases I could probably live with the risk that the method is inexact in the
case of timestamp discontinuities.


>
> >> > (being exact while ffmpeg is a few frames off, but that's a different
> >> > topic), so there must be a faster way to implement it.
> >>
> >> Patch probably welcome.
> >>
> >
> > My asking is actually with the motivation to get enough information about
> > the problem as possible to decide whether to offer sponsoring for a patch
> > implementing the behaviour I describe, so it's good to know a patch would
> > be welcome.
> >
> >
> >>
> >> > Tested with a number
> >> > of different files with identical results in principle.
> >>
> >> > What keeps confusing me is that analyzeduration and probesize really
> >> > seem
> >> > to be the parameters that should address the behaviour
> >>
> >> No, you misunderstand "analyzeduration", it does not analyze the
> >> duration of the input but specifies the duration that should be used
> >> for analysis.
> >>
> >
> > That's how I understood it, so in my tests I set it to a value beyond the
> > duration of the file so that, if needed, the entire file is parsed for
> > calculating its duration (as well as setting probesize to a value larger
> > than the file size) but that did not happen.
>
> Sorry for being unclear: The "analysis" does not contain file duration.
>

Thanks, I did not know that. That is a good explanation for what I observe.

Robert