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. > > > (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. Robert > > Carl Eugen > _______________________________________________ > 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". _______________________________________________ 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".
