I think I need to bite the bullet and do workaround 1. The problem here is if either changes the way they report the time of a file I'd be in trouble.
#FFMPEG CUT VIDEO BY TIME UPTO MILLISECONDS PRECISE PLUS#
If they return different answers, I could assume the true value is the ffmpeg answer plus 7 milliseconds. If both give the same answer, I could then assume the true time is the answer returned plus 2 milliseconds. From what I can tell, ffmpeg always rounds the time down, while mencoder will round up to the next hundreth when milisec is 5 or more. A video might have two codecs one for the video track and another for the audio track. Since bash doesn't handle floating point I find this kind of thing to be a pain.Ģ) Get within 3 miliseconds by comparing the answers from ffmpeg and mencoder. Fortunately, FFmpeg allows for copying the codec from the original video to the trimmed video, which takes only a few seconds.
I might have to do this but I'd have to write a function to get the framrate and then do the conversions. Is anyone aware of a common linux command line tool which I could use to tell how long a segment of video is down to the thousandth of a second?īarring this, I've thought of two possible workarounds:ġ) Determine the precise time using the frame rate of the stream. Unfortunately once I've cut a video stream all ffmpeg, mencoder, or transcode will tell me is the length of the stream down to the hundredth of a second.
With sox I can cut and recombine audio down to the milisecond, and this to my ears at least is flawless. This could create a problem when the end results are combined back together because from my own testing even a hundredth of a second of silence is noticeable. I can cut and combine video streams flawlessly with ffmpeg and not loose or gain a frame. I'm running into a problem ensuring that the audio doesn't get stepped on when the streams are cut and then recombined. I've explained in another thread some of the tinkering I'm doing creating my own video effects, etc.
0 kommentar(er)
