On Tue, Dec 18, 2018 at 11:40 PM Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2018-12-18 21:49 GMT+01:00, Robert Krüger <krueger@lesspain.software>: > > On Fri, Dec 14, 2018 at 5:28 PM Carl Eugen Hoyos <ceffm...@gmail.com> > wrote: > > > >> 2018-12-14 17:19 GMT+01:00, Robert Krüger <krueger@lesspain.software>: > >> > On Fri, Dec 14, 2018 at 3:03 AM Carl Eugen Hoyos <ceffm...@gmail.com> > >> wrote: > >> > > >> >> 2018-12-13 17:10 GMT+01:00, Robert Krüger <krueger@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 _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
