Recherche avancée

Sur d’autres sites (9168)

• Static ffmpeg library windows

  29 novembre 2022, par peter

  Im trying to use the ffmpeg libraries (libavutil, libswscale, ...) in a bigger project by statically linking them, im not interested in the binaries. Now the issue comes down to getting them statically built. I tried searching for pre-compiled builds but without success.

  


  Following the docs, i compiled them on wsl2 for win64 with

  


  ./configure --arch=x86_64 --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --disable-shared --enable-static
make


  


  After that i copied the libavformat/libavformat.a as libavformat.lib (which should be fine since they are cross-compiled ar archives ?) into my project and linked them with CMake.

  


  When compiling smth like

  


  AVFormatContext* pFormatContext = avformat_alloc_context();


  


  i get a linker error saying

  


  lld-link : error : undefined symbol: avformat_alloc_context


  


  When looking at the libs with dumpbin -linkermember libavformat.lib, i can see

  


  >dumpbin -linkermember libavformat.lib
...
  135CD92 _avformat_alloc_context
...


  


  notice the underscore.

  


  Can i not link the cross-compiled *.a files directly into a windows executable ?

  


  Honestly at this point any ideas are welcome.

  


  Thanks

  


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

  


• x86 : hevc_mc : save 1 gpr in epel filter loading

  7 février 2015, par Christophe Gisquet

  x86 : hevc_mc : save 1 gpr in epel filter loading
  The 3*stride value stored in r3src can be loaded much later,
  
  so use r3src instead of a dedicated gpr when possible.
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/x86/hevc_mc.asm