[FFmpeg-user] [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 only when using tee muxer

[Carl Eugen Hoyos]

2019-03-05 16:45 GMT+01:00, Michael Kohne <mhkohne at moberg.com>:
> On Fri, Feb 22, 2019 at 7:31 AM Michael Kohne <mhkohne at moberg.com> wrote:
>
>> On Thu, Feb 21, 2019 at 9:35 AM Carl Eugen Hoyos <ceffmpeg at gmail.com>
>> wrote:
>>
>>> 2019-02-21 15:24 GMT+01:00, Michael Kohne <mhkohne at 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