I've downloaded and applied this workaround to two movies. I haven't watched either from beginning to end, but I did preview them. When skipping forward through either movie, around ¾ of the way through the picture turns solid gray except for some colored pixels at the top that continuously change.
________________________________ From: ffmpeg-user <ffmpeg-user-boun...@ffmpeg.org> on behalf of Tefl Zuren <sjx2...@hotmail.com> Sent: Saturday, December 15, 2018 6:08 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] Using ffmpeg with youtube-dl: Non-monotonous DTS in output stream Not an optimal solution, but it works. Thanks. Could this be a feature request in ffmpeg or libavformat to have it handle concatenating multiple mpegts segments correctly when their timestamps aren't continuous? ________________________________ From: ffmpeg-user <ffmpeg-user-boun...@ffmpeg.org> on behalf of Gyan <ffm...@gyani.pro> Sent: Friday, December 14, 2018 11:47 PM To: ffmpeg-user@ffmpeg.org Subject: Re: [FFmpeg-user] Using ffmpeg with youtube-dl: Non-monotonous DTS in output stream On 15-12-2018 07:15 AM, Tefl Zuren wrote: > I'm trying to download a video with youtube-dl > (http://rg3.github.io/youtube-dl/). It uses ffmpeg. At the beginning of the > second group of mpegts files, ffmpeg starts throwing the error > "Non-monotonous DTS in output stream 0:0; ... This may result in incorrect > timestamps in the output file." and continues for the remainder of the > download. The saved mp4 file is only playable up to 20:26 then it freezes. > This problem usually occurs only on the TNT and TBS websites. The output is: > [hls,applehttp @ 0x23c7900] Opening > 'https://tve.cdn.turner.com/tnt/83b278d50b415d38d9d85e6584e23004/layer7/seg.key' > for reading > [hls,applehttp @ 0x23c7900] Opening > 'crypto+https://tve.cdn.turner.com/tnt/83b278d50b415d38d9d85e6584e23004/layer7/seg-0_00000.ts' > for reading > Input #0, hls,applehttp, from > 'https://tve.cdn.turner.com/tnt/83b278d50b415d38d9d85e6584e23004/layer7/layer7_bk.m3u8?hdntl=exp=1544853868~acl=%2ftnt%2f83b278d50b415d38d9d85e6584e23004%2f*~hmac=421213acd762b1be021249cc78935d1141e301a3b8f31e73318c0131dc384093': > Duration: 01:29:01.24, start: 1.466733, bitrate: 0 kb/s > Program 0 > Metadata: > variant_bitrate : 0 > Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, > 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, > 59.94 tbc > Metadata: > variant_bitrate : 0 > Stream #0:1: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, > fltp > Metadata: > variant_bitrate : 0 > [hls,applehttp @ 0x23c7900] Opening > 'crypto+https://tve.cdn.turner.com/tnt/83b278d50b415d38d9d85e6584e23004/layer7/seg-0_00001.ts' > for reading > ... > [hls,applehttp @ 0x23c7900] Opening > 'crypto+https://tve.cdn.turner.com/tnt/83b278d50b415d38d9d85e6584e23004/layer7/seg-0_00204.ts' > for reading > [hls,applehttp @ 0x23c7900] Opening > 'crypto+https://tve.cdn.turner.com/tnt/83b278d50b415d38d9d85e6584e23004/layer7/seg-1_00000.ts' > for reading > [mp4 @ 0x2479700] Non-monotonous DTS in output stream 0:0; previous: > 110426426, current: -6006; changing to 110426427. This may result in > incorrect timestamps in the output file. > [mp4 @ 0x2479700] Non-monotonous DTS in output stream 0:0; previous: > 110426427, current: -3003; changing to 110426428. This may result in > incorrect timestamps in the output file. > [mp4 @ 0x2479700] Non-monotonous DTS in output stream 0:0; previous: > 110426428, current: 0; changing to 110426429. This may result in incorrect > timestamps in the output file. > [mp4 @ 0x2479700] Non-monotonous DTS in output stream 0:0; previous: > 110426429, current: 3003; changing to 110426430. This may result in incorrect > timestamps in the output file. > [mp4 @ 0x2479700] Non-monotonous DTS in output stream 0:0; previous: > 110426430, current: 6006; changing to 110426431. This may result in incorrect > timestamps in the output file. Some playlists contain a sequence of separately produced MPEG-TS files. So, there's a timestamp reset when each new segment is received. At this point, the timestamp code in libavformat's mux.c simply increments the output timestamp by one when this happens. Unless the timebase resolution is 1/fps, this produces an unsound file. Workaround is to extract the individual streams and remux using mp4box. ffmpeg -i downloaded.mp4 -c copy video.h264 ffmpeg -i downloaded.mp4 -c copy audio.aac mp4box -add video.h264 -add audio.aac -new fixed.mp4 Gyan _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
