Recherche avancée

Sur d’autres sites (3367)

• ffmpeg segment naming - Moving to superuser (with apologies)

  21 juillet 2022, par kenneth558

  Maybe I am misinterpreting the downvote, but I conclude this question should go on superuser instead. Moving now and will delete this copy soon....

  


  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)

  


• 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)

  


• ffmpeg mjpeg encoding not recognized by VLC on other device

  25 juin 2023, par Harsh Kumar

  Let me describe the case scenerio first :

  


  I am using RaspberryPi as a USB-UVC gadget to stream a video to a host device connected via USB cable to the Pi .
For this i have a application(may see if you want) which is succesfully streaming the a USB camera live stream using ./uvc-gadget -d /dev/video0 on the Pi side where /dev/video0 is a real USB camera and the rest is just a syntax of application to take the input as some v4l2 capture device.On the Host side i have to just open the VLC and select capture device as the UVC-Camera made by the apllication and play the stream by selcting the MJPG option under the advanced options and only MJPEG format is supported by the application.

  


  So what i thought that is to make a virtual camera device using sudo modprobe v4l2loopback first (/dev/video1 for now ) and then feeding a my Raspberry desktop screen to it using ffmpeg and then feeding this /dev/video1 virtual video capture device to my application as ./uvc-gadget -d /dev/video1.

  


  More graphically,

  


  Desktop screen -> virtual camera -> apllication

  


  But unfortunately i am not getting the desired results given that this service is supported by the appllication (you may refer readme of application) .I get the trival error of 'Your input device can,t be opened ' in VLC when i do the same steps .

  


  Summary ,
I guess i may be doing something wrong for the MJPEG encoding using ffmpeg also ,
Here is the command i am using ,
ffmpeg -probesize 100M -framerate 30 -f x11grab -video_size 1280*720 -i :0.0+0,0 -c:v mjpeg -pix_fmt yuvj422p -f v4l2 /dev/video1.

  


  Also , i checked on raspberry the output of dev/video1 is fine and also tried removing the pix_fmt yuvj422p thinking that it might causing some conflict with color encoding but got the same error.

  


  Will be very thankful if someone can help me figuring out the erorr.
Thanks for your time and patience .