Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
[Crunchyroll] ffmpeg complains of non-monotonous DTS in output stream, produces broken video #10719
Comments
|
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. |
|
@rhinitis What is your ffmpeg version? Tried with 3.1.4, but the bug is still here. |
|
@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. |
|
I can confirm using the HEAD ffmpeg solves this issue (version 3.3.r82175.g5a123f1). On Archlinux you can install |
|
Thanks for testing. I'll leave this issue open until ffmpeg 3.3 is released. |
|
I tested recently released stable ffmpeg 3.2, with which the issue seems already solved. |
|
Thanks! Closing. |
|
@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 See my comment to #14934 for details. |
…fe for the content but might help mkv's non-monotonous DTS. ytdl-org/youtube-dl#10719 (comment) https://superuser.com/questions/908295/ffmpeg-libx264-how-to-specify-a-variable-frame-rate-but-with-a-maximum
|
@eladkarako Thanks for the message. However, I've done some more investigation (literally, just now) and concluded that The symptom? Check any MKVs you've muxed with Having said that, my original remark does still stand for a specific type of muxing problem. My current hypothesis is as follows:
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 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 [edit:] @eladkarako Oh, i now see that maybe you avoided the problems with |
|
@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 |
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)