On Tue, Mar 5, 2019 at 11:25 AM Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 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 > > Dredging up this question again - I have not had the time to play with the delay and adelay filters, hopefully soon. To refresh the memory, I'm trying to transcode a stream two to avi files by using the tee muxer, and the errors are: [avi @ 0x9873ba0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1104 >= 1104 [avi @ 0x987d2a0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1104 >= 1104 I got around the issue for the moment by simply double-encoding, but I want to try to understand what's going on. My question of the moment is: Does the muxer (specifically the AVI muxer) push any kind of information back upstream to the encoder? Because if it does, then that might explain the problem - the tee muxer might not be quite up to merging that info from two instances of the muxer, and things go to hell from there. Michael Kohne Senior Software Engineer Office: 215.283.0860 x208 mhko...@moberg.com -- Celebrating 20 Years Transforming Neurocritical Care Moberg Research, Inc. 224 S Maple Street, Ambler, PA 19002 24/7 Customer Support: 888.662.7246 www.moberg.com <https://www.moberg.com/> _______________________________________________ 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".
