[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

[Michael Kohne]

On Tue, Mar 5, 2019 at 11:25 AM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:

> 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
>
>
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
mhkohne at 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/>