On Sat, 26 Jan 2019 at 10:19, Marton Balint <c...@passwd.hu> wrote: > On Sat, 26 Jan 2019, Meredydd Luff wrote: > Why do you need an internal queue for this? If I am getting this right, > you inject blank frames and then pass the input as is. > > A possible real world use case would be useful for me to better understand > what you want to do.
Motivating example: we are capturing live video and audio, where for reasons beyond our control the audio has been delayed by, say, 10 seconds. We want to delay the video to match. If we just inject blank frames and adjust tps of subsequent frames (which is what tpad does - sorry for misstatement in previous message), then this works for short delays (eg sub-1-second). Beyond that, we get all sorts of sync weirdness, with the video freezing for extended periods of time or forever. My guess is that the plumbing (I'd very speculatively raise my eyebrows in the direction of the frame_wanted/back-pressure machinery) isn't dealing well live capture when something's messing with the pts but otherwise leaving everything in the same buffers. So I built a filter with an internal one-in-one-out buffer that seems not to have this problem. In short, this does not work: ffmpeg -i /dev/video0 -f pulse -ac 2 -i default -vf tpad=start_duration=10 -t 20 output.mkv This does: ffmpeg -i /dev/video0 -f pulse -ac 2 -i default -vf delay=60 -t 20 output.mkv Meredydd _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
