Mark Filipak (ffmpeg) wrote > On 01/28/2021 07:42 PM, pdr0 wrote: >> Mark Filipak (ffmpeg) wrote >>> But perhaps by "process in parallel" you mean something else, eh? >>> ...something I'm unaware of. Can >>> you expand on that? >> >> >> I mean "divide and conquer" to use all resources. If you're at 20% CPU >> usage, you can run 4-5 processes >> >> eg. Split video in to 4-5 segments. Process each simultaneously, each to >> a >> lossless intermediate, so you're at 100% CPU usage. Then reassemble and >> encode to your final format > > I don't think that will work very well, even if I carefully cut on key > frames. The reason is that > the minterpolate filter drops 10 frames and that means that at the join of > each section there'll be > a 1/6 second jump (or maybe worse).
This has nothing to do with keyframes; I'm not talking about stream copy. eg. -vf trim splits in the uncompressed domain (data is decoded to uncompressed frames) . If you need to you can split stages as lossless intermediates You cut on cadence boundaries of 24 frame cycles. 24p is evenly divisible into 120p (5x) . 60p takes every 2nd frame from that 120p result this is what you are doing with optical flow retiming, so every frame is evenly spaced in time. > Note: Whether the minterpolate filter drops 10 frames or 5 frames is the > subject of [FFmpeg-user] > minterpolate PTS v frame count weirdness. Not sure what this is referring to ? Any more details ? If you're getting PTS , frame count weirdness, split it out as lossless intermediates -- Sent from: http://ffmpeg-users.933282.n4.nabble.com/ _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
