Andrew Church wrote: >> This works and is obviously a lot simpler than the long list of -c >> values I'm using right now, but the speed is actually slower -- around >> 173 fps vs 205 fps when I use the -c flag. >> It's also not as precise -- I get 418 images per hour instead of 360 as >> I should -- and do with the -c flag. >> I take that back -- the 418 was an artifact, the number of resulting images is more than twice that expected, as below. > > That's certainly unusual. If you can install CVS HEAD, can you see whether > it gives you the same behavior? Another thing to try is to run transcode > both ways (with --frame_interval and with the -c list) and see where the > two sets of images diverge; it could be a constant, small slip, or there > could be some point in the video where transcode gets confused and skips > the wrong number of frames. > These are production machines so I can't install CVS at the moment -- but I did try the two switches on the same file.
The first result is that "--frame_interval 300" exports a frame every five seconds rather than every ten (NTSC) -- to get the ten-second interval I have to use "--frame_interval 600" (looks like a bug?). The second result is that using "--frame_interval 600" is still different from using -c timecodes, because NTSC is 29.97 and not 30. Image 241 by the frame_interval method is frame 72000 -- but that is 00:40:02.400, so the interval is not an exact ten-seconds. The -c timestamps, however, stay on the millisecond -- image 241 is frame 71928, which is 00:39:59.997. Now that's close enough! :) To use the frame_interval and export a frame every ten seconds, I would need to be able to use a framerate switch, as in -f 29.970. The workaround is to use the long list of -c timecodes I posted earlier; it actually works flawlessly, though of course it has to be scripted. > As far as the speed goes, it may be that --frame_interval causes the frames > to be decoded even though they're going to be dropped. I don't think the > skipping code has received much attention, so there are probably things > that could be optimized in that code path. > The speed difference isn't very dramatic -- but with the -c switch I get an explicit "skipping frames [002099-002397]", while with the framerate switch I get "encoding frames [000000-080249]" as if every frame is encoded. > Thanks for the suggestion; I'll put it on my list of things to do (when I > have time--sigh). > Hey, I know -- really appreciate your work on this, it makes all the difference. For now I can live with this: nice -n 19 transcode -o $FIL.img/$FIL.img -y im -F png -x ffmpeg,null -i $FIL.avi -c \ 0:00:00-0:00:00.1,0:00:10-0:00:10.1,0:00:20-0:00:20.1,0:00:30-0:00:30.1,0:00:40-0:00:40.1,0:00:50-0:00:50.1,\ 0:01:00-0:01:00.1,0:01:10-0:01:10.1,0:01:20-0:01:20.1,0:01:30-0:01:30.1,0:01:40-0:01:40.1,0:01:50-0:01:50.1,\ 0:02:00-0:02:00.1,0:02:10-0:02:10.1,0:02:20-0:02:20.1,0:02:30-0:02:30.1,0:02:40-0:02:40.1,0:02:50-0:02:50.1,\ 0:03:00-0:03:00.1,0:03:10-0:03:10.1,0:03:20-0:03:20.1,0:03:30-0:03:30.1,0:03:40-0:03:40.1,0:03:50-0:03:50.1,\ 0:04:00-0:04:00.1,0:04:10-0:04:10.1,0:04:20-0:04:20.1,0:04:30-0:04:30.1,0:04:40-0:04:40.1,0:04:50-0:04:50.1,\ 0:05:00-0:05:00.1,0:05:10-0:05:10.1,0:05:20-0:05:20.1,0:05:30-0:05:30.1,0:05:40-0:05:40.1,0:05:50-0:05:50.1,\ 0:06:00-0:06:00.1,0:06:10-0:06:10.1,0:06:20-0:06:20.1,0:06:30-0:06:30.1,0:06:40-0:06:40.1,0:06:50-0:06:50.1,\ 0:07:00-0:07:00.1,0:07:10-0:07:10.1,0:07:20-0:07:20.1,0:07:30-0:07:30.1,0:07:40-0:07:40.1,0:07:50-0:07:50.1,\ 0:08:00-0:08:00.1,0:08:10-0:08:10.1,0:08:20-0:08:20.1,0:08:30-0:08:30.1,0:08:40-0:08:40.1,0:08:50-0:08:50.1,\ 0:09:00-0:09:00.1,0:09:10-0:09:10.1,0:09:20-0:09:20.1,0:09:30-0:09:30.1,0:09:40-0:09:40.1,0:09:50-0:09:50.1 and so on for 75 minutes. Wouldn't want to type that in every time. Dave
