Hello, I apologize for posting this issue here again, as it has been discussed before, but unfortunately the solution we came up with has not solved the problem entirely. Here is the story:
I have a RTSP stream coming from a Hikvision NVR that uses H.264 encoding for video and G.711ulaw for audio. My goal is to re-stream it using HLS to a HTML5 website. The problem is audio PTS that is completely messed up which results in normal transcoding of it being impossible: 1. ffmpeg -rtsp_transport tcp -i rtsp://the_source -qscale 2 -c:v copy -c:a aac -flags -global_header -hls_time 10 -hls_list_size 6 -hls_wrap 10 -start_number 1 C:\inetpub\wwwroot\HLS\stream1C.m3u8 When opening this HLS stream using ffplay the video plays at 5 times its normal speed due to incoherent PTS of the audio. So what I do is I change the container format to something that supports streams to normalize the PTS and then pipe the output to another instance of ffmpeg for HLS: 1. ffmpeg -rtsp_transport tcp -i rtsp://the_source -qscale 2 -c:v copy -c:a aac -f avi - | ffmpeg -i - flags -global_header -hls_time 10 -hls_list_size 6 -hls_wrap 10 -start_number 1 C:\inetpub\wwwroot\HLS\stream1C.m3u8 This does result in sane playback for approximately 15-25 minutes but after that time I get a lot of “Non-monotonous DTS in output stream 0:0; previous: 27000, current: 4500; changing to 27001. This may result in incorrect timestamps in the output file.” Messages, and as soon as they appear – I lose the audio when playing this HLS stream in ffplay and after a lot of these exact same messages the video freezes as well. I have tried changing the container formats to other candidates but none of them give better results than avi. Another solution was to use an ancient build of ffmpeg that according to answers to similar questions had different mechanism for dealing with inconsistent DTS/PTS issues so I tried a lot of versions for the past 7 years and when I regressed back to FFmpeg version git-00ba041 built on Mar 1 2011 01:00:35 I got some interesting results – the above warning message no longer appeared (probably was not even implemented on this build) and the stream did not freeze but there was another problem: after a while the stream would fall behind in terms of time. After about 2 hours of streaming, the HLS stream would be approximately 10 minutes behind than the original RTSP stream and it got worse from there on. Eventually, after about 24-46 hours the ffmpeg instance would crash. And the crashing would be fine once every 24-46 hours but the falling behind part is a problem. What bothers me the most is that if I open the RTSP stream directly in ffplay without transcoding anything, it plays straight without freezing or any other problems. I have observed it for more than 48 hours. Another thing is that If I only stream video then everything goes fine – no freezing or errors whatsoever: 1. ffmpeg -rtsp_transport tcp -i rtsp://the_source -qscale 2 -c:v copy -an -flags -global_header -hls_time 10 -hls_list_size 6 -hls_wrap 10 -start_number 1 C:\inetpub\wwwroot\HLS\stream1C.m3u8 Providing a sample file won’t do much good for the RTSP stream so here is the stream URL itself: rtsp://admin:[email protected]:554/Streaming/channels/101 Is it possible to force the video DTS to ‘dictate’ the timestamps to the audio? As it seems that it is only audio PTS that is messed up. Thank you, Kind regards George A. _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
