Recherche avancée

Sur d’autres sites (15447)

• ffmpeg segment naming of rtsp surveillance stream HikVisions

  20 juillet 2022, par kenneth558

  I need to ensure unique segment names : Apparent POE cable defects, etc. around campus cause HikVision camera streams to require their ffmpeg daemons re-started once or twice or more times/day. (I am miles away from this campus for the most part, so I prefer a command line fix until the hardware fixes get applied.) When ffmpeg has to be restarted for a camera (by background bash script), I need the names of the new .mp4 segments positively not to be the same as any previous names.

  


  Background bash process currently does fine to specify an acceptable ddHHMM style new starting name for the first segment after ffmpeg restart BUT after the first or sometime second or third segment is made, ffmpeg insists on future naming to default to an unacceptable YYYmmdd style and thus start to overwrite previous segments. I use "$(date +%d%H%M)" to obtain my acceptable date style.

  


  I've tried a lot of different combinations of date codes and date embedding and both ssegment and segment muxers ; also I know very little of the very complex realm that ffmpeg is normally used in outside of simple rtsp stream copy to .mp4 files.

  


  ffmpeg command that is launched from inside bash script :
bash -c 'nohup ffmpeg -nostdin -stimeout 10000000 -rtsp_transport udp -i "rtsp://192.168.0.11:6554/Streaming/channels/101" -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -c:v libx264 -f ssegment -strftime 0 -segment_time 180 -segment_format_options movflags=+faststart -reset_timestamps 0 -increment_tc 1 -avoid_negative_ts 1 -c copy -flags +global_header /var/www/camera_streams/camera_east_driveway/"$(date +%d%H%M)"_%3d.mp4 > /dev/null 2>/dev/null & '

  


  Can the segment naming pattern be carried forward indefinitely like I want ? Honestly, I wonder if ffmpeg does not allow for my specific use case naming need ?

  


  (Yes, I know changing from udp to tcp can help, but I don't consider it to be the specific solid naming fix I'm hoping for right now. And I mention HikVision in case there is known frame encoding differences for them than other cameras)

  


• Configure NVR to accept video stream from IP camera routed through PC

  11 juin 2021, par BenStackover

  I currently have an IP camera connected to an ethernet port on my PC. I also have my PC connected to a network switch via another ethernet cable. I have a NVR connected to the same network switch. I would like to be able to access the video stream from the camera (that is connected to the PC) on the NVR. I have tried restreaming the camera feed using ffmpeg and udp :

  


  ffmpeg -i 'rtsp://user:pwd@192.168.xxx.xxx:554' -preset ultrafast -tune zerolatency -codec:v libx264 -f mpegts udp://admin:admin@192.168.yyy.yyy:8090

  


  where the xxx.xxx is my PC and yyy.yyy is the NVR however the NVR cannot connect. If I connect another PC to the same network switch and change yyy.yyy to that PC's IP I can view the stream.

  


  I have also tried setting up ffserver as an rtsp server using ffserver and can view the rtsp stream from the first PC on the second PC using ffplay rtsp://192.168.xxx.xxx/test1.sdp on the second PC after launching the server on the first PC. I cannot connect to the same stream from the NVR.

  


  Can anyone tell me if what I am attempting to do is even possible ? Ie. how can I make my NVR see a video stream that isn't directly from an IP camera ?

  


  Any help would be much appreciated.

  


  Thanks !

  


• Controlling "Real-Time" sending rate in RTP Streaming with FFMpeg

  14 décembre 2020, par Robert_Ordis

  I'm trying to build an experimental audio telephony system with ffmpeg to talk some G.711 VoIP machine.

  


  Then, I tried this command.

  


  .\ffmpeg.exe -re -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -ac 1 -ab 64k -ar 8000 -f mulaw -f rtp "rtp://192.168.3.175:4449?fifo_size=240&localrtpport=5100&pkt_size=240"


  


  In WireShark capturing, the audio in each packets was actually divided in each around 30[ms].

  


  However, 17- 18 packets was sent together once per 500[ms].

  


  Sent audio was correct, but in this situation, an opponent machine can't treat this correctly.

  


  How do I send these packets in per "UNDER 0.5 SEC" ?