bakaid commented on a change in pull request #612: MINIFICPP-854: Capture RTSP
Frame
URL: https://github.com/apache/nifi-minifi-cpp/pull/612#discussion_r304461584
##########
File path: extensions/opencv/CaptureRTSPFrame.cpp
##########
@@ -73,6 +73,11 @@ void CaptureRTSPFrame::initialize() {
relationships.insert(Success);
relationships.insert(Failure);
setSupportedRelationships(std::move(relationships));
+ // By default in OpenCV, ffmpeg capture is hardcoded to use TCP and this is
a workaround
+ // also if UDP timeout, ffmpeg will retry with TCP
+ // Note:
+ // 1. OpenCV community are trying to find a better approach than setenv.
+ setenv("OPENCV_FFMPEG_CAPTURE_OPTIONS", "rtsp_transport;udp", 1);
Review comment:
@phrocker I see your point, but I am a little afraid of adding functionality
to the minifi.sh. When debugging, for example, you do not start to debug the
shell running the minifi, but start debugging the minifi binary itself. If you
do that, and the minifi.sh does not set the environment variables, it will have
a different behaviour. I know that this is avoidable, but I am sure that more
than one people would make this mistake.
Setting (and getting) environment variables from inside the process is
perfectly supported, but not thread safe. Having the setenv in an
ObjectFactoryInitializer, when the application is single threaded and the
ObjectFactoryInitializers are called in sequence should not be a problem.
I do not think either solution is bad, but I feel that the
ObjectFactoryInitializer would be better.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
