2019-03-05 16:45 GMT+01:00, Michael Kohne <mhko...@moberg.com>: > On Fri, Feb 22, 2019 at 7:31 AM Michael Kohne <mhko...@moberg.com> wrote: > >> On Thu, Feb 21, 2019 at 9:35 AM Carl Eugen Hoyos <ceffm...@gmail.com> >> wrote: >> >>> 2019-02-21 15:24 GMT+01:00, Michael Kohne <mhko...@moberg.com>: >>> > ./ffmpeg -min_port 62000 -max_port 62004 -i rtsp:// >>> > 192.168.0.113/media/video1 -codec:v msmpeg4v2 -codec:a ac3 -ar 44100 >>> -map 0 >>> > -f tee "[f=avi]/data/vidtmp/one.avi|[f=avi]/data/vidtmp/two.avi" > >>> > /data/vidtmp/out.txt 2>&1 >>> >>> You do realize that by separating the command line >>> from the console output, you make it harder to >>> understand the issue? >>> >> I'll try to not do that in the future. >> >> >>> Does it work with "-re"? >>> >>> No, -re has no effect. Here's a run with -re set - same issue as the >> original run. >> >> <snip log from previous message> > > Given that -re didn't work, is there something else I should be doing to > try to understand this? > I'd prefer to not double my CPU usage by avoiding the 'tee' muxer. > I guess the first question is: Is this a bug in some way? Is it supposed to > do this for some reason that's unclear to me?
The tee muxer is very special, I hoped that somebody else who has used (or better: implemented) it would comment. You could test the delay and adelay filter, I don't know the exact options out of my head but I am curious if they at least can delay the issue you see. Carl Eugen _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".