MPV error 'non monotonically increasing dts' when encoding a dynamically loaded playlist to output stream.

[twilson90]

Important Information

mpv 0.31.0-67-g63bf362d11
Windows 10

Reproduction steps

I want to use MPV to encode a dynamic playlist of items - that is, a playlist that can be altered during playback / encoding.
It important to make the point that I am not using the mpv command line to input my playlist or files. The playlist is generated dynamically after mpv is started, controlled by an IPC interface.
The input files are of all different shapes and size, different frame rates, etc.

With a set of video files, I can quite easily merge them into one seamless video stream using the mpv commandline, with the help of --merge-files and some filters to give them a consistent format.

However, if I insert those same files dynamically with IPC commands with the same set of filters and encoding options, I will all too often encounter a crash at the transition point between files.

Here's an example command for how I start MPV:

mpv --idle --msg-level=ipc=v --no-osc --keep-open=yes --merge-files --input-ipc-server=\\.\pipe\mpvserver --of=mpegts --ovc=libx264 --ovcopts=profile=main,preset=veryfast,level=4,crf=20,maxrate=5000k --vf=lavfi=[format=yuv420p,scale=(iw*sar)*min(1280/(iw*sar)\,720/ih):ih*min(1280/(iw*sar)\,720/ih),pad=1280:720:(1280-iw*min(1280/iw\,720/ih))/2:(720-ih*min(1280/iw\,720/ih))/2] --oac=aac --oacopts=ac=2,b=160k --o=out.ts

I hope there's a simple fix for this.
I've already spent countless hours writing a web-app and node server that allows me to control MPV remotely, and it's only in this last stage of testing that I've encountered this problem.

[ghost]

The commands you send up until the crash and the files involved would probably help. You also forgot to attach the log file.
I have my doubts that this kind of "continuous" encoding really works though.

[twilson90]

The only commands I'm sending are to load the playlist and to observe a few properties.
That's not the issue.

I was a bit tight for time last night and forgot the log. Here it is:
mpv.log

I believe the culprit is this, my arch nemesis - the non-monotonically increasing DTS warning:

[ 4.427][w][ffmpeg] aac: Queue input is backward in time
[ 4.428][e][ffmpeg] mpegts: Application provided invalid, non monotonically increasing dts to muxer in stream 0: 5389438 >= 5385596

After that it crashes.

However it doesn't crash if I load the playlist as a command line input with the --merge-files param.

Edit 1: Also worth noting it doesn't crash if I exclude the --o param so I can see the GUI (which I've been doing all throughout testing...)

Edit 2: Here are the files I'm using, but I'm sure you can probably use any 2 videos and encounter this error: https://drive.google.com/open?id=1hSKkhgd04UVHZeWZ-OW44Yp5g3NP2XTj

[ghost]

No google drive.

Does it actually crash, or just exit?

[ghost]

Oh, nevermind, actually looking at the log shows:

[   4.428][e][encode] Writing packet failed.

That's a fatal error. It pretty much complains about timestamps going backwards, for whatever reasons. Normally, some code in there should compensate that in the normal case.

Edit: performing some more tests with this:

1. Stopping "playback" and then starting a new file does not work because the decoder gets deinitialized; could probably be worked around if there's any interest.
2. Loading a new file during "playback" just works.
3. --merge-files probably doen't do what you think it does, and encoding mode in theory supports concatenating multiple files just by putting them on the internal playlist.

And as a general comment: everything other than mpv pure playback handles format changes badly (including encoding mode), so you may need to awkwardly prevent this with video and audio filters, unless mpv somehow gets special support for that.

[twilson90]

I was just about to post your second point - Loading a new file during "playback" works.

Considering that, there should be a simple workaround for this problem.

I tried making this app with VLC originally and I had a similar problem, it couldn't handle the transition between videos. Rather than crash it just spewed out a load of DTS errors. The sound continued to play but the video froze. But when I piped VLC's output into an ffmpeg process, ffmpeg managed to sew the 2 streams together to create 1 seamless video.
I've tried the same with mpv but it's not working unfortunately, because MPV prefers to crash.

[ghost]

Can't tell without reproduction. There is no crash.

[twilson90]

Your last response doesn't make any sense to me. Sorry.

[twilson90]

Still haven't found a way around this.

The fact it works if I load the playlist via the command line, or if I skip to the next playlist item, would indicate that a fix can be easily implemented.

I would really appreciate if someone took a closer look at this issue.

[ghost]

Like I said, needs reproduction/files.

[twilson90]

Earlier you said you'd been performing tests and confirmed the bug essentially:

Stopping "playback" and then starting a new file does not work because the decoder gets deinitialized; could probably be worked around if there's any interest.

and

Loading a new file during "playback" just works

But then you said:

Can't tell without reproduction. There is no crash.

Can you see why I'm a little confused? I assumed you'd re-produced the bug from your earlier post but then you appear to contradict yourself.

The command I'm using is in the initial post, and after that just simply send a couple of commands to load 2 files into the playlist via the IPC interface (or any interface that doesn't trigger the GUI)

I've posted video samples to test on, but you can use any video file to confirm this behaviour.

[ghost]

https://en.wikipedia.org/wiki/Crash_(computing)
Don't use words in a confusing way.
And as I said, I won't take samples from google drive.

[twilson90]

I appreciate that you're trying to help but please be a little less cryptic in your responses.
I'm none the wiser why my use of the word 'crash' is incorrect or misleading, assuming that's what you meant.

Here's a sample vid again:
https://mega.nz/#!g9IAGCpI!Bw1i6DVlm93Du5saJ52zGak319SGMHudaOOPQXzbPYc
https://www.dropbox.com/s/ocysv0r3v4if4cu/pig.mkv?dl=0

Or assuming zips aren't a problem for you:
pig.zip

If you load it into the playlist twice via IPC and you should encounter the error at the end of the first item, supposing you're using --out

[ghost]

Tried that, and I get two pigs as output. Maybe make a log with the pig.

[twilson90]

mpv.log

It's the same issue as before:

[   2.002][w][ffmpeg] aac: Queue input is backward in time
[   2.003][e][ffmpeg] mpegts: Application provided invalid, non monotonically increasing dts to muxer in stream 1: 2878020 >= 2877122
[   2.003][e][encode] Writing packet failed.

If I remove the audio track from the source video, start mpv with the same arguments and send the same commands, it doesn't error.

[ghost]

You should try with a more recent mpv version then. Preferably git master.

[twilson90]

I'm using the latest release (20200315-git-281f5c6) and I still consistently get this error.

[ghost]

I'm not getting it, with the exact command line from the first post (just added --no-config). You'll need to explain the timing of the other commands then.

[twilson90]

Let's simplify down it to the bare essentials then. I run this command:

mpv --no-config --input-ipc-server=\\.\pipe\mpvsocket --idle --o=out.mkv --log-file=mpv.log

Then I wait a moment for mpv to load, then:

echo {"command":["loadfile","pig.mkv"]} >\\.\pipe\mpvsocket
echo {"command":["loadfile","pig.mkv","append"]} >\\.\pipe\mpvsocket

I can only assume there's an inconsistency between your ffmpeg lib and mine.

That said, I'm sure there must be a configurable ffmpeg option that can easily fix this.

[twilson90]

I've just tested the above code on a remote server running Ubuntu 16.04 (changed slightly so the commands execute correctly)... and it worked.
No ffmpeg error.

This issue appears to be for Windows only.

[twilson90]

--

[twilson90]

Just bumping this in the hope that someone with Windows could look into this.

A simpler way to test this is to simply call:

mpv pig.mkv pig.mkv --no-config --of=mpegts --ovc=libx264 --ovcopts=profile=main,preset=veryfast,level=4,crf=20,maxrate=5000k --vf=lavfi=[format=yuv420p,scale=(iw*sar)*min(1280/(iw*sar)\,720/ih):ih*min(1280/(iw*sar)\,720/ih),pad=1280:720:(1280-iw*min(1280/iw\,720/ih))/2:(720-ih*min(1280/iw\,720/ih))/2] --oac=aac --oacopts=ac=2,b=160k --o=out.mkv

Because the behaviour will be exactly the same as adding files dynamically through the playlist.
I know I could add the --merge-files argument to the above command to make it work, but that's not the point. In order to recreate the behaviour of a dynamic playlist we can't add that.

On my remote Ubuntu server the command works perfectly, creating an output file with the 2 videos seamlessly joined.
On Windows, after the first file I see 'non monotonically increasing dts', then it exits. It only outputs the first video.

I recommend using the test file I uploaded last week, pig.mkv, as I've found it doesn't run into this error with some other video files I've tested. However, just to clarify, the video encoding is not corrupted or of an unusual standard. It's a standard mkv with h264 + aac tracks. I'm not sure why some work and some don't but I suspect it's to do with the completeness of the last segment of audio:
https://github.com/mpv-player/mpv/files/4334259/pig.zip

It doesn't matter what version of mpv I use on Ubuntu or Windows, the behaviour of each remain the same.

---

EDIT:
OK, it turns out that my Ubuntu server is now also logging the dts error and exiting.
In the last few days I updated it from an older version and this must have changed the behaviour...

This is the version I'm using on Windows:
mpv 0.32.0-258-g281f5c63c1
git-2020-03-14-425b6a9a2

This is the version I'm using on Ubuntu:
mpv git-2019-04-25-71ad1e2
ffmpeg version: git-2019-04-28-3dee6c0

[ghost]

Do you have the ffmpeg git version number from when it worked?

It's also possible that it's just some kind of race condition (though somewhat unlikely).

[twilson90]

I just managed to get it to work again on an earlier version.... much earlier in fact.
The version that worked:
mpv 0.14.0
ffmpeg version: 2.8.15-0ubuntu0.16.04.1

[ghost]

That is decades old.

[twilson90]

I know. It's the version that I got when I ran 'apt-get install mpv', before adding a dedicated repo on Ubuntu 16.04.

[ghost]

You can easily build it yourself. mpv-build may be helpful to try different ffmpeg versions. Requires you to use git etc. though.

[twilson90]

Rather than building mpv with an older version of ffmpeg (I assume that's what you mean) I'd rather configure mpv to not exit when it encounters 'non monotonically increasing dts'.
But I'd need help with that.

[ghost]

That's a ffmpeg bug. (They'd rather abort than allowing us to write possibly, but not really, invalid timestamps.)
To make mpv tolerate this I'd need a reproduction. I'm also playing with the thought of writing an own mkv muxer to work around these problems, but of course this wouldn't help with ts output.

[twilson90]

I can't think why you aren't running into the same problem as me when you run the same command with (presumably) the latest build of mpv + ffmpeg.
If you have any ideas why please let me know.

[ghost]

Actually I can reproduce it with that command line now, for whatever reason.
Will investigate later.

[twilson90]

Thanks! Hope you can find an effective solution to this problem.
Your help is very much appreciated.

[ghost]

It's probably fixed now, but I lost motivation somewhere along the way. Encoding mode is now deprecated. I suggest you find a better way to implement what you want, without mpv.

[ghost]

Hm, possibly encoding mode could be salvaged by stepping around the old design, in a way that avoids the severe problems with it. Have to think about this. Encoding/muxing itself is a pretty simple thing.

[twilson90]

It's probably fixed now, but I lost motivation somewhere along the way. Encoding mode is now deprecated. I suggest you find a better way to implement what you want, without mpv.

I went looking and all I found was VLC and mpv.
For my project I need all the functionality of a video player, that I can alter on the fly and output a video stream, without a GUI.
I've tried already VLC and it's buggy as hell. I just couldn't depend on it to run reliably.
mpv is so much better. The only problem is this 'non monotonically increasing dts' error.

I really appreciate the work you've put in, and I'd ask not to do away with the encoding mode just yet. Even if it is a bit quirky at times, it's very useful and I've not come across another video player that matches it.

I'll try building mpv now to give it a whirl.
Thanks again.

[ghost]

vlc is in theory better, because it was designed to be a streaming server.
The current way mpv treats audio timestamp for encoding is terrible nonsense, and while it (probably) works for now (in many situations), it just has no future. There are 3 things that could happen:

• the mpv audio chain changes enough that the audio timestamp can actually be passed through properly
• that new idea I have, where encoding sidesteps the current output layer (so it can actually get all the timestamps)
• encoding mode bitrots more and gets removed

The original author of the encoding mode doesn't have time anymore, so what happens is open.

[twilson90]

I managed to compile a windows build using MSYS2.
Good news: It works (kind of) ... if I don't use any video filters.
However if I try using the scale or pad filter it silently exits... it works in GUI mode though.
Not sure if there's something wrong with my build or if the latest commits caused a separate issue.
The log doesn't provide any clues.

mpv pig.mkv --no-config --log-file=mpv.log --of=mpegts --ovc=libx264 --ovcopts=profile=main,preset=veryfast,level=4,crf=20,maxrate=5000k --vf-add=format=yuv420p --vf-add=scale=1280:720 --oac=aac --oacopts=ac=2,b=160k --o=out.mkv

mpv.log

EDIT: Just tried rewinding back to commit cdd6eb0 and those filters are working.
Must be a problem with a recent commit.
I'll start a new issue...

EDIT2: #7555

[ghost]

I've reverted part on this on master, but on the other hand, audio timestamp handling should be significantly better now. Still very much alpha-quality code though.

[twilson90]

I still have this issue too with slightly 'bad' media files.

Example of badly encoded media file:
https://0x0.st/iRJz.mp4

When checked with ffmpeg I get the following errors with said media file:

[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4 >= 3
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 6 >= 6
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 9 >= 9
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 11 >= 11
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 15 >= 15
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 17 >= 17
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 23 >= 23
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 25 >= 25
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28 >= 28
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 31 >= 31
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 34 >= 34
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 37 >= 37
[null @ 0000021e69921080] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 43 >= 43
etc...

And when I try to encode this file in mpv it immediately quits and produces the following log:
mpv-2020102512743218.log

But the media file in question plays perfectly fine in mpv GUI mode.

Can we make it so the encoder is a bit more robust when it comes to these sorts of minor errors?

[frozenpandaman]

@hedgehog90 Did you ever solve this? Running into this issue as well when using the dump-cache command (on Mac)…

[twilson90]

@frozenpandaman I wrote a fix on my fork that works for me.
https://github.com/hedgehog90/mpv
The branch is named something like 'more robust encoder'.

[gsantner]

@hedgehog90
Question, did you create a merge request or something, is the fix included in mpv already? Also running into this bug. I couldn't see a PR though at last and your branch/repo is (or is gonna be) outdated sooner or later.

[twilson90]

I wrote the 'fix' specific for my configuration, wouldn't recommend merging.
You can see what I did and apply it to a new fork:
twilson90@1da9de8