[FFmpeg-user] Problematic RTSP re-streaming

Fri Aug 24 17:46:12 EEST 2018

Hello George,

Thanks for the prompt response. This is not the issue I discussed.

My issue is that the remap filter is returning black and white output.
I am using the latest ffmpeg version. I am facing the same issue as discussed in the thread:

https://ffmpeg.org/pipermail/ffmpeg-user/2017-November/037971.html

That is remapping produce black and white output. If I use the workaround of using the format conversion then the processing slows down very drastically.

One more thing to add is if I use yuv444p then the output is encoded coloured.

Command producing black and white:

Fps: 29

ffmpeg -y -stream_loop -1 -i silence.mp3 -r 30 -i rtmp://172.104.245.86/live/test  -i sample2160_x.pgm -i sample2160_y.pgm -lavfi "remap" -vcodec h264_nvenc -pix_fmt yuv420p -b:v 10000k -f flv rtmp:xxxx

Command producing colored output:

Fps: 20

ffmpeg -y -stream_loop -1 -i silence.mp3 -r 30 -i rtmp://172.104.245.86/live/test -i sample2160_x.pgm -i sample2160_y.pgm -lavfi "remap" -vcodec h264_nvenc -pix_fmt yuv444p -b:v 10000k -f flv rtmp:xxxx

Fps: 12

ffmpeg -y -stream_loop -1 -i silence.mp3 -r 30 -i rtmp://172.104.245.86/live/test  -i sample2160_x.pgm -i sample2160_y.pgm -lavfi " format=pix_fmts=rgb24,remap" -vcodec h264_nvenc -pix_fmt yuv420p -b:v 10000k -f flv rtmp:xxxxx

Another interesting observation is that if I use ffmpeg version 3.3.2 then below mentioned command gives 
20 fps with colored output

ffmpeg -y -stream_loop -1 -i silence.mp3 -r 30 -i rtmp://172.104.245.86/live/test  -i sample2160_x.pgm -i sample2160_y.pgm -lavfi "remap" -vcodec h264_nvenc -pix_fmt yuv420p -b:v 10000k -f flv rtmp:xxxx

Can you please tell me if this bug can be rectified as we want to achieve colored 29fps with this setup.

Thank you.

Best regards,
Shaji Baig

Sent from my iPhone

> On 24 Aug 2018, at 16:40, George Andguladze <gandguladze at hotmail.com> wrote:
> 
> 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:Horse99@213.131.57.126: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
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".