Recherche avancée

Sur d’autres sites (8183)

• Checking if IP Camera is connected or not with cv2 faster ?

  15 novembre 2022, par Barış Aktaş

  I have code that works on 2 IP Cameras but before running my main algorithm I would like to check if my IP Cameras are connected or not. I wrote this code and i have used it before with 2 USB cameras now i am having a problem with IP Cameras.

  


  import cv2 

def check_connnections():
    #Check cam1
    cam1_ok = False    
    cam1 = cv2.VideoCapture('rtsp://admin:Tom12345.@192.168.0.33:554/onvif1') 
    if cam1.isOpened():
        cam1_ok = True

    #Check cam2
    cam2_ok = False
    cam2 = cv2.VideoCapture('rtsp://admin:Tom12345.@192.168.0.33:554/onvif1') 
    if cam2.isOpened():
        cam2_ok = True

    print(f'Cam1 Connection Status: {cam1_ok}')
    print(f'Cam2 Connection Status: {cam2_ok}')


check_connnections()


  


  Now if i plug the cameras i get :
Cam1 Connection Status: True , Cam2 Connection Status: True and when i unplug the cameras i expect Cam1 Connection Status: False , Cam2 Connection Status: False but it takes 3 minutes for cv2.VideoCapture() function to finish and return Falseif the IP cameras are not connected while it runs instantly for USB cameras. Is there a faster way to check this ?

  


  I tried same thing with USB Cameras, i also tried try:... except:pass but i couldn't find i way.

  


• FFMPEG Screen Flashing Green

  18 novembre 2022, par Devin Dixon

  I have this problem where my ffmpeg videos are flicking green. Example of the video is here :
https://www.glitch.fun/streams/31fea7e0-7523-4365-9780-31deee9e472c/watchrecording/efb841c0-4b87-4482-b165-990880a66f63

  


  My ffmpeg command is this :

  


  /usr/bin/ffmpeg -vaapi_device /dev/dri/renderD128 -y -v info -f x11grab -draw_mouse 0 -r 60 -s 1920x1080 -thread_queue_size 14000 -i :0.0+0,0 -f alsa -thread_queue_size 14000 -i plug:bsnoop -acodec aac -strict -2 -ar 44100 -b:a 128k -af aresample=async=1 -c:v h264_vaapi -vf format=nv12|vaapi,hwupload -preset medium -maxrate 14000k -bufsize 14000k -pix_fmt yuv420p -r 60 -crf 25 -g 120 -tune zerolatency -f flv rtmp://ingest.bingewave.com/live/[output_to_livestream] -pix_fmt yuv420p -r 60 -b:v 15000k -maxrate 15000k -bufsize 15000k -c:v h264_vaapi -vf format=nv12|vaapi,hwupload -preset medium -keyint_min 24 -level 3.0 -g 120 -tune zerolatency -f flv rtmp://127.0.0.1:1935/live/[output_to_recording]


  


  The reason why my fps and bitrate is so high and preset is so medium is because Glitch is an open source esports platform, and those kinds of settings are required for streaming of game graphics
The command has two outputs :

  


  

  • rtmp ://[output_to_livestream] goes to a livestream where users watch live

  


  • rtmp ://127.0.0.1:1935/live/[output to recording] goes a goes to a file

  


  


  And the output to the recording is captured by nginx and saved to a file as such :

  


  rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            #Set this to "record off" if you don't want to save a copy of your broadcasts
            record all;
            # The directory in which the recordings will be stored.
            record_path /var/www/html/recordings;
            record_unique on;
            record_suffix -%d-%b-%y-%T.flv;
            on_record_done http://127.0.0.1:3000/recorded;
            # Turn on HLS
            exec /usr/bin/ffmpeg -vaapi_device /dev/dri/renderD128 -i rtmp://127.0.0.1:1935/live/$name -c:v copy -c:a copy -f flv rtmp://127.0.0.1/show/$name;
        }

        application show {
            live on;
            # Turn on HLS
            hls on;
            hls_path /mnt/hls/;
            hls_fragment 3;
            hls_playlist_length 60;
            # disable consuming the stream from nginx as rtmp
            deny play all;
        }
    }
}


  


  So the part that goes to the live is fine, no green flickering at all. But the part that goes to the recording is one that goes the above issue :

  


  -pix_fmt yuv420p -r 60 -b:v 15000k -maxrate 15000k -bufsize 15000k -c:v h264_vaapi -vf format=nv12|vaapi,hwupload -preset medium -keyint_min 24 -level 3.0 -g 120 -tune zerolatency -f flv rtmp://127.0.0.1:1935/live/[output_to_recording]


  


  I
s there something I need to be changing here ?

  


• ImageJ / Fiji shows wrong number of frames in video (FFMPEG import)

  28 avril 2023, par locoric_polska

  I am counting the number of animals in a an area using Fiji. I import the video through the FFMPEG plug-in (videos are mp4 with mpeg-4 codec). However, I noticed that when I import the videos Fiji uploads the wrong number of frames, and I cannot understand why and how.

  


  An example. I have a video shot at 25fps which is 1582s long. If I do the calculations the video should have 39550 frames in total (1582*25). When I open it through a Computer vision package in R, I see that the video correctly contains 39550 frames. However, when loaded in Fiji, the shown number of frames is 49511. So Fiji is adding 9961 frames to the video. This is consistent across all videos that are recorded in 25fps, while it does not appear in videos shot at 24fps.

  


  Curiously, I found that the ratio between the number of frames read by Fiji and the 'real' number of frames is consistent between 0.79 and 0.80. This makes me think that Fiji is expecting the video to be 30fps and (possibly) duplicating frames to adjust the video to this assumption.

  


  Unfortunately, I discovered all this after finishing my analysis and while trying to merge this dataset with another obtained through CV. The number of frame does not match between datasets and I am not sure how to solve this.

  


  Any help would be greatly appreciated !!

  


  An idea is to multiply all the frame numbers by 0.8 to adjust them to the old assumption. This solution assumes that Fiji is duplicating frames throughout the video in a consistent way