Configuration tolerance for network loss

Question

I have a motion setup with IP cameras and I am having some issues. I have very bad video quality due to network loss. I have tested the camera quality with ISpy and VLC they all have video quality issues so it is not just Motion. I have tested the network and I measured 5% loss with JPerf. I may not be able to fix this network loss. 5% is not that large of a loss but it is causing major issues. I do not know how to check my versions but everything is freshly complied from source. I have a recording to show my quality:

https://drive.google.com/file/d/0B4JSHhNONAZubU5TMUFPano2bms/view?usp=sharing

I am hoping this can be compensated for in software. Is there a configuration setting that can adjust for the loss of an I frame? I assume the loss of an update frame would be harder to deal with but is it possible? Is there maybe another software package that can intercept the video stream fix it then send it to Motion?

Environment

Motion version:	3.2.12
ffmpeg version:
Libraries:	ffmpeg, motion
Server OS:	Raspbian

-- MichaelGoff - 21 Nov 2015

motion: invalid option -- 'v'
motion Version Unofficial-Git-2caced3, Copyright 2000-2005 Jeroen Vreeken/Folkert van Heusden/Kenneth Lavrsen

Thanks for the link but I have no idea what to do with it, should I just recompile the main branch? If I do and it compiles with the new features what setting option do I use to force it to use TCP?

* edit

I have been trying to get ffmpeg freshly compiled but I occasionaly get dropped from ssh. Not a relevant issue but it is time consuming starting over. Is the setting "rtsp_uses_tcp" done in the thread config or durring the recompile of motion?

* edit

It is a setting in the threadx.conf. I changed it to on and motioneye set it to off. Using the video device > extra motion options - did set it and keep it on. This my be what I am looking for...

** edit -

I have set this setting and it has made a huge difference. But, there is still a small problem. I'd like it fixed but if it cannot be then I guess I can live with it. Here is a recording with the problem in it:

https://drive.google.com/file/d/0B4JSHhNONAZuNVV4anJpV3VkY3c/view?usp=sharing

This video cuts off my head and moves it back some. I can still make out what is going on in the video but is there a fix for it?

Answer

Typing motion -v will provide the version number. For the particular problem, you may want to try using a updated source. If the network camera is using rtsp, then we know that SVN and github Sackmotion were using a UDP transport method that does corrupt frames. The choice of using a rtsp transport was incorporated into a proposed patch that you can get via the testing debs or source.

http://www.lavrsen.dk/foswiki/bin/view/Motion/PatchworkForNewRelease

Follow up

There are some attached files at the bottom of the link that had deb files, patches and tarballs. BUT, even though I gave you the wrong parameter, motion did report the version number which was what I wanted. I can see from this that you are in fact using the same code proposed for next version. There is therefore no need to recompile or reinstall anything. The initial posting indicated version 3.2.12.

Now, with the issue: If you accepted the defaults on the parameter, there may not be much that can be done. The option is rtsp_uses_tcp This is forces the use of tcp instead of udp and usually fixes network connection issues.

One additional investigation point. I know that you have indicated that it is a network issue. But have you ruled out the pi getting overloaded? You have many options turned on that take lots of CPU. Detection boxes, pixel changes, labels, MP4 encoding. It is possible that the PI is getting overloaded. You may also want to try a different output format just to see if the problem persists. The MP4 was introduced for the first time in Sept. so there could be something in the creation of the MP4 rather than network (No one has reported anything but it is still being "tested" )

If it does seem that the MP4 is the cause, I'd recommend first making sure you have the latest builds of ffmpeg and preferably building from source. There could be some optimizations that would improved the quality.

Follow up on the edit:

If the default is for rtsp_use_tcp to be "off", then you should probably report that as a issue back to MotionEye. There is virtually no situation I can contemplate in which it is preferable to not have that "on" and that is how the standard distributed configuration file from Motion is provided.

The latest issues could be the CPU limitations. As previously mentioned, the boxes and pixel notices, labels, etc do take a lot of CPU to create which would slow down the FPS that can be processed and as a result lead to the affect in the video. My IP cameras actually have two streams and if yours does as well you may want to consider setting up a script. Have Motion monitor the Low quality stream and if Motion is detected, have it trigger a script that records the high quality stream without doing any re-encoding. The other parameters that may have an effect is the ffmpeg vbr and bitrate. I have seen better results with the VBR. Possibly also look at what the camera is sending and possibly change that to a constant bit rate. So, bottom line, I think you'll have to experiment a bit to do the tradoffs.