Recherche avancée

Sur d’autres sites (11273)

• 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 stereo track stops capturing at random times during a capture session

  26 mai 2022, par mrwassen

  I am currently working on building a workflow to capture and archive a large stash of family and friends PAL and NTSC VHS tapes. The hardware setup is as follows :

  


  

  • JVC HR-7860S VCR

  


  • s-video / RCA audio >

  


  • ADVC-3000 converter

  


  • SDI / BNC cable >

  


  • Blackmagic Decklink Mini Recorder 4K PCIe card

  


  • installed in a fairly hi-spec windows machine : AMD Ryzen 9 5900X 3.7 Ghz base 12 core, GEFORCE RTX 3060 12 gB, 32 gB ram

  


  


  The plan is to capture to lossless AVI, then drop into an NLE (Vegas Pro v.16) to do a minimal amount of cleanup / trimming, then render to a more compressed video format (TBD) for upload to AWS S3 accessible through a family website.

  


  The issue I am having is that when I run the capture using ffmpeg/directshow e.g. for a perfectly fine 90 min. PAL tape, at some random point of time during the capture one of the 2 stereo channels just stops capturing. This has happened with all of the tapes I have tested so far, and it happens at different times during the same video. I have examined the frames surrounding points in time when this happens, and it doesn't correlate to any transitions or jitter, but often just randomly in the middle of a perfectly smooth scene. Once the one channel stops capturing it never starts back up again during that capture session.

  


  The ADVC-3000 and the VCR are both showing both stereo channels playing normally throughout the capture. The windows machine running the capture hardly breaks a sweat at any time, and the transfer easily keeps up constantly showing a speed = 1x which I assume means nothing lagging. Also there are no video/audio sync issues at any point in time even towards the end of long tapes e.g. 90 mins.

  


  I am fairly new at ffmpeg, so I have spent extensive amounts of time reading up on forum posts and experimenting and have ended up with the following syntax :

  


  ffmpeg -y -f dshow -rtbufsize 2000M -i video="Blackmagic WDM Capture":audio="Blackmagic WDM Capture" -codec:v v210 -pix_fmt yuv422p -codec:a pcm_s16le -b:a 128k -t 02:00:00 -r 25 -threads 4 -maxrate 2500k -filter:a "volume=1.5" output_v210_audio.avi


  


  The capture runs without a single dropped frame, the only error I am getting when launching (and perhaps this is a smoking gun ?) is :

  


  


  "Non-monotonous DTS in output stream 0:1 ; previous : 0, current : -30 ;
changing to 1. This may result in incorrect timestamps in the output
file."

  


  


  I have tried to troubleshoot this in the hopes that it is tied to my issue but so far without luck.

  


  Hoping somebody can help correct or modify my command line or perhaps other ideas to help resolve the issue.