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