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

[Carl Eugen Hoyos]

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.

>> > (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.

Carl Eugen