record error

[cl84]

when I log an rtmp or mpegts stream after a few seconds it stops logging and returns the following errors in the logs

[2022-01-21 16:10:37.454] E [StreamWorker:30957] FFmpeg | third_parties.cpp:111 | [AVFormatContext: 0x7f7e88022380] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 219920 >= 219920 [2022-01-21 16:10:37.454] E [StreamWorker:30957] FileWriter | file_writer.cpp:394 | error = -22

[getroot]

It looks like your encoder is sending the wrong timestamp. If not, please provide a way to reproduce this issue.

Please provide information about the encoder you are using and your Server.xml and full ovenmediaengine log file. And please provide the procedure how to reproduce it.

[cl84]

I use ffmpeg to restream with the following command: ffmpeg -i 'rtsp://admin:270972@192.168.1.46:554/cam/realmonitor?channel=1&subtype=0&unicast=true' -ac 2 -acodec aac -vcodec copy -f flv -ar 44100 rtmp://127.0.0.1/app/camera2

the configuration file is the following:

OvenMediaEngine origin * false stun.l.google.com:19302 8081 1 8082 10 1 1935 1 9999 1 4000-4010/tcp 3333 10 *:3478 true *:10000/udp 1 9000 1 3333 3334 10 *:3478 true *:10000/udp 1 * /etc/apache2/ssl/apache.crt /etc/apache2/ssl/apache.key tauro@2017 default ovenmediaengine.com * /etc/apache2/ssl/apache.crt /etc/apache2/ssl/apache.key 3000 60000 /app/ rtsp 127.0.0.1:554/ app live false bypass_stream ${OriginStreamName} stream_${Port} 4000-4010 30000 /var/www/html/Registrazioni /${VirtualHost}/${Application}/${Stream}/${StartTime:YYYYMMDDhhmmss}_${EndTime:YYYYMMDDhhmmss}_${Sequence}.mp4 /${VirtualHost}/${Application}/${Stream}.xml 1 8 30000 false false false 5 3 * 5 3 * urn:mpeg:dash:utc:http-xsdate:2014 /time?iso&ms 5 *

[Keukhan]

@cl84

It is thought that there is a problem with the video track in the RTSP stream of the camera. The dts value of the video packet should be increased sequentially, but it does not seem to be the case.

Can I access the rtsp camera from an public network? or, if you send me the dumped TS file using ffmpeg, I will find a solution.

Thanks.

[Keukhan]

@cl84

Another solution is try encoding the video codec instead of the copy option in the ffmpeg command and sending it.

ffmpeg -i 'rtsp://admin:270972@192.168.1.46:554/cam/realmonitor?channel=1&subtype=0&unicast=true' -ac 2 -acodec aac -vcodec copy -f flv -ar 44100 rtmp://127.0.0.1/app/camera2

to

ffmpeg -i 'rtsp://admin:270972@192.168.1.46:554/cam/realmonitor?channel=1&subtype=0&unicast=true' -ac 2 -acodec aac -vcodec libx264 -f flv -ar 44100 rtmp://127.0.0.1/app/camera2

Thanks

[cl84]

would it not be possible to eliminate the control of the dts? the stream part in webrtc works correctly and without problems, not only the recording part goes

Thank you

[getroot]

You can use it by modifying the code in the location below. (It would be better to control error code -22.)

https://github.com/AirenSoft/OvenMediaEngine/blob/7aa27d4e6ddf063a9462aa01912ae101ed907c8d/src/projects/publishers/file/file_session.cpp#L346

But patching this with the official code requires more thought and testing.

Simply dropping the duplicate DTS packets will record normally in your case, otherwise the video file may be corrupted or of poor quality. In this case, it is very difficult for some users to determine the cause. This is especially true for file recordings rather than live playback (WebRTC).

The best thing to do is to get the correct input.

[cl84]

The source specifically is a dahua ip camera, I can't in any way make a restream of the rtsp stream without giving dts errors.

I have also tried with other ip cameras and I have the same problem.

Is it possible that you fail to record a live camera stream with ome?

[getroot]

I think the best solution would be to make ffmpeg send the correct pts and dts. I did a Google search for you.

https://stackoverflow.com/questions/46796992/ffmpeg-flv-0xbeee10-non-monotonous-dts-in-output-stream

https://stackoverflow.com/questions/65634283/ffmpeg-livestream-by-ip-camera-with-a-problem-of-dts

Keywords like genpts, igndts, use_wallclock_as_timestamps, -re might help you.

If you find a solution in the ffmpeg community or elsewhere, please share your experiences for users of OME.

[getroot]

I closed this issue because it has been inactive for a long time. If further discussion is needed, please do not hesitate to reopen the issue.