Closed mystise closed 8 years ago
rhinitis
commented
8 years ago I had the same problem. This seems a bug of ffmpeg, and fortunately I found it is fixed in the latest version of ffmpeg. There is no stable release yet, so you need to build ffmpeg from source.
emersion
commented
8 years ago @rhinitis What is your ffmpeg version? Tried with 3.1.4, but the bug is still here.
rhinitis
commented
8 years ago @emersion I built ffmpeg from source, from the "master" branch of the repository (see "Get the Sources" on https://www.ffmpeg.org/download.html). Maybe the fix won't be included in stable releases until version 3.2.
emersion
commented
8 years ago I can confirm using the HEAD ffmpeg solves this issue (version 3.3.r82175.g5a123f1). On Archlinux you can install ffmpeg-git from AUR (you'll have to rebuild mpv if you use it, install mpv-git).
yan12125
commented
8 years ago Thanks for testing. I'll leave this issue open until ffmpeg 3.3 is released.
rhinitis
commented
8 years ago I tested recently released stable ffmpeg 3.2, with which the issue seems already solved.
yan12125
commented
8 years ago Thanks! Closing.
glenn-slayden
commented
5 years ago @eladkarako Thanks for the suggestions, but they didn't work for me. The problem is to get ffmpeg's matroska muxer to ignore or repair corrupt dts timestamps when the video source is otherwise ok.
Eventually, I discovered that adding -vsync drop to the ffmpeg.exe command worked:
See my comment to #14934 for details.
glenn-slayden
commented
5 years ago @eladkarako Thanks for the message. However, I've done some more investigation (literally, just now) and concluded that -vsync drop should only be used as a last resort.
The symptom? Check any MKVs you've muxed with -vsync drop to make sure that they don't speed by with a free-running frame rate. That is, the video just plays as fast as possible, with the player displaying every frame immediately as soon as it is decoded, and without introducing a possibly necessary timing delay. Check with a couple different media players if necessary.
Having said that, my original remark does still stand for a specific type of muxing problem. My current hypothesis is as follows:
-vsync drop with ffmpeg is the only way to prevent the [matroska] muxer from fatal failure/exit when it encounters a timestamp that has already passed.-vsync drop fix really only works for the specific case where the failure point is at (or near) the end of media.In many of the cases I originally needed to fix, it was the last timestamp that was invalid (in fact, it was zero). These are the cases that were fully-corrected by specifying -vsync drop, obviously because it doesn't matter what happens after that point.
However, I subsequently discovered some other files that had timestamp errors much earlier in the file (or right at the beginning), and in these cases, the resulting MKV cannot really be considered "repaired," because the frame rate starts free-running from the point of failure to the end.
Summary: only use -vsync drop as a last resort for repairing MKV timestamps.
[edit:] @eladkarako Oh, i now see that maybe you avoided the problems with -vsync drop—but while still getting the main benefit, namely point 1.) above—by also having genpts etc. which I didn't use. I'll try those when I get a chance to see if we've actually landed on a universal, general-purpose solution.
Nottt
commented
4 years ago @eladkarako this is one of the top results when googling for this error.
Is it safe to use your flags for muxer for all input ? It doesn't seem to fix te non-monotonous DTS error for me anyway.
What do you recommend to people just looking to copy video, subtitles and audios to a output, in batch mode, and trying to fix issues like this
mindbane
commented
2 years ago I am on ffmpeg version 4.2.7 and still having this issue on
Make sure you are using the latest version: run
youtube-dl --versionand ensure your version is 2016.09.19. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.Before submitting an issue make sure you have:
What is the purpose of your issue?
If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows:
Add
-vflag to your command line you run youtube-dl with, copy the whole output and insert it here. It should look similar to one below (replace it with your log inserted between triple ```):Output from test on premium video:
Description of your issue, suggested solution and other information
Downloading from Crunchroll (on videos that don't require a premium account) passes off to ffmpeg instead of hlsnative. Ffmpeg prints a large number of the same error with different values, complaining of "Non-monotonous DTS in output stream:; previous: , current: ; changing to . This may result in incorrect timestamps in the output file." A few seconds into the final video file the audio restarts back to the beginning, thus offsetting the audio for the rest of the video. (Tested in MPV. Strangely enough, this only offsets the audio if you actually watch the part of the video that is messed up, if you skip over it the audio is in sync for the rest of the video) In certain cases, it also messes up the video, jumping back to the beginning of the video for a short while, then continuing on. (Tested in MPV as well, moving forwards frame by frame shows it, moving backwards after moving over the corruption skips back to the beginning of the corruption)
Audio corruption happens all the time, video corruption is sometimes only visible on stepping frame by frame.
Downloading a premium video passes off to rtmpdump instead of ffmpeg, and does not produce a corrupted output.
Tested on the following URLs: http://www.crunchyroll.com/erased/episode-1-flashing-before-my-eyes-691793 (video and audio corruption) http://www.crunchyroll.com/rewrite/episode-11-countdown-715027 (video and audio corruption) http://www.crunchyroll.com/rewrite/episode-12-the-song-of-destruction-715029 (premium video, no corruption. In a week this will no longer be a premium video, in which case pick any simulcasting show and the newest episode should always be premium)