Recherche avancée

Sur d’autres sites (3784)

• ffmpeg : transmission problems / artifacts in rtsp screen grab - might be a WiFi problem

  1er décembre 2022, par Jo Kerner

  In short : Is there a way to "force" ffmpeg to not save a grabbed frame if there are transmission problems ? Or any other software that does the same and I just don't know of ?

  


  Long story :

  


  Updating my house surveillance from almost 10 years old DCS-932L cameras to Tapo C100 Cameras, I changed the image delivery method from ftp push to rtsp grab via ffmpeg.

  


  I had written a program in C++ to check for "bad" pictures from the old cameras, where parts of the picture tended to be simply black once every minute or so (I'm grabbing a pic every 2 seconds). The Tapo C100 doesn't feature ftp-push, thus I tried (after a few days trying)

  


  ffmpeg.exe -y -i rtsp://user:pass@10.0.0.%ld:554/stream1 -vframes 1 %scamera\rtsp.jpg -loglevel quiet


  


  This works absolutely perfect in my main house, which features a Fritz !Box 7590 and a set of Fritz !Powerline (510/and two 540e) repeaters, plus one WiFi repeater Fritz 600) as my phone line and the router are in the basement.

  


  In my holiday home, though, it doesn't. The Wifi is managed by a Hybrid DSL/5G - box I have no alternative to, which is a Huawei DN9245W and works as DHCP Server, because this is almost impossible to change. Everything "real" is managed by another Fritz !Box 7590, connected via ethernet, and another set of Fritz !Powerline 510 and two 540e repeaters plus half a dozen Wifi Repeaters, mostly Fritz ! 310, 450E and 600. The house was partially built with local stones, which are very iron-y, and there's a lot of metallized glass. Full set is show in Image

  


  Now, this does produce different artifacts, about two per minute or in every 15th picture, see
Image with artifacts No. 1

  


  Thinking this might be a transmission problem, I tried forcing the streamgrab via TCP, because while rtsp doesn't have error correction, TCP does :

  


  ffmpeg.exe -rtsp_transport tcp -i
rtsp://user:pass@10.0.0.%ld:554/stream1 -y -f image2 -update 1 -r
1 -vframes 1 -qscale:v 30 %scamera\rtsp.jpg -loglevel quiet


  


  Which didn't change the artifacts much, see Image with artifacts No. 2

  


  The house now has a total of 12 Cameras, six of which are each "managed" by an older Dell Optiplex Desktop bought used off ebay with an i3 or i5 processor from about 2015, which goes to about 65% load. My software will check if the grabbed picture is finished saving (to RAMdisk), rename it, check if there are artifacts, if so, drop it, if not, convert to bitmap and then compare it to previous image, guess if there's a change, mark that change with a rhombus and rate it, save that as a jpeg file, and then some other stuff that's not relevant here. See : Image of my program running with six cameras

  


  I did try grabbing keyframes only, but a bunny or deer or burglar hopping through my property doesn't produce a keyframe, so that turned out to be missing the point.

  


  I'm out of ideas here. It does work flawlessly in the main house. It doesn't in the holiday house. I can hardly install more repeaters ; I already tried mesh and not-mesh, and the problem isn't exactly wifi overload, because even with just one camera running, it still persists. In certain places. Some have no problems. Reasons ? No clue. I really hope someone has a good idea.

  


• FFMpeg on Android, undefined references to libavcodec functions, although it is listed on command line

  1er juin 2016, par dimsuz

  I have a problem with unresolved references to ffmpeg’s libavcodec functions, so far failed to find the answer in other places (including my mind) :)

  Let me describe my setup - it takes space, but is really basic, it might be that I’m failing to see some error...

  I built an FFMPeg with ndk r5 toolchain, ffmpeg port I got from http://bambuser.com/opensource (as recommended in other questions here). It built fine, so I put several static libraries in my project like this :

  <project>/jni/bambuser_ffmpeg/libavcodec.a
  
  <project>/jni/bambuser_ffmpeg/libavformat.a
  
  <project>/jni/bambuser_ffmpeg/libavcore.a
  
  <project>/jni/bambuser_ffmpeg/libavutil.a
  
  </project></project></project></project>

  Next, I created an Android.mk in bambuser_ffmpeg folder to list these libs as a prebuilt ones :

  LOCAL_PATH := $(call my-dir)
  
  
  
  include $(CLEAR_VARS)
  
  LOCAL_MODULE := bambuser-libavcore
  
  LOCAL_SRC_FILES := libavcore.a
  
  include $(PREBUILT_STATIC_LIBRARY)
  
  
  
  include $(CLEAR_VARS)
  
  LOCAL_MODULE := bambuser-libavformat
  
  LOCAL_SRC_FILES := libavformat.a
  
  include $(PREBUILT_STATIC_LIBRARY)
  
  
  
  (same for other two libs)

  Next, I have another module which references these libs in its Android.mk, sets up include paths, etc :

  LOCAL_PATH := $(call my-dir)
  
  
  
  include $(CLEAR_VARS)
  
  
  
  LOCAL_MODULE := ffmpegtest
  
  LOCAL_STATIC_LIBRARIES := bambuser-libavcodec bambuser-libavcore bambuser-libavformat bambuser-libavutil
  
  LOCAL_SRC_FILES := ffmpeg_test.cpp
  
  LOCAL_C_INCLUDES := $(LOCAL_PATH)/../bambuser_ffmpeg/include
  
  LOCAL_LDLIBS    := -llog -lz
  
  
  
  include $(BUILD_SHARED_LIBRARY)

  And finally I have my ffmpeg_test.cpp which is really basic, like this :

  #include 
  
  
  
  extern "C" {
  
  #include <libavcodec></libavcodec>avcodec.h>
  
  #include <libavformat></libavformat>avformat.h>
  
  }
  
  
  
  extern "C" {
  
      JNIEXPORT jint JNICALL Java_com_the7art_ffmpegtest_PaintThread_testFFMpeg(JNIEnv* env, jobject obj, jstring fileName);
  
  }
  
  
  
  JNIEXPORT jint JNICALL Java_com_the7art_ffmpegtest_PaintThread_testFFMpeg(JNIEnv* env, jobject obj, jstring fileName)
  
  {
  
      av_register_all();
  
      return 0;
  
  }

  When I run ndk-build, it compiles fine, but when linking it prints an unresolved reference to almost every function in libavcodec. Looks like only this lib’s functions are failing to be located :

  /home/dimka/src/mobile/android/ffmpegtest/obj/local/armeabi/libavformat.a(allformats.o) :
  In function

  av_register_all':
 /home/dimka/work/suzy/tmp/ffmpeg-android/ffmpeg/libavformat/allformats.c:47:
 undefined reference to
 

  avcodec_register_all’
  /home/dimka/src/mobile/android/ffmpegtest/obj/local/armeabi/libavformat.a(utils.o) :
  In function

  parse_frame_rate':
 /home/dimka/work/suzy/tmp/ffmpeg-android/ffmpeg/libavformat/utils.c:3240:
 undefined reference to
 

  av_parse_video_rate’
  /home/dimka/src/mobile/android/ffmpegtest/obj/local/armeabi/libavformat.a(utils.o) :
  In function

  parse_image_size':
 /home/dimka/work/suzy/tmp/ffmpeg-android/ffmpeg/libavformat/utils.c:3234:
 undefined reference to
 

  av_parse_video_size’
  /home/dimka/src/mobile/android/ffmpegtest/obj/local/armeabi/libavformat.a(utils.o) :
  In function

  flush_packet_queue':
 /home/dimka/work/suzy/tmp/ffmpeg-android/ffmpeg/libavformat/utils.c:1277:
 undefined reference to
 

  av_free_packet’
  /home/dimka/work/suzy/tmp/ffmpeg-android/ffmpeg/libavformat/utils.c:1283 :
  undefined reference to

  av_free_packet'
 /home/dimka/src/mobile/android/ffmpegtest/obj/local/armeabi/libavformat.a(utils.o):
 In function

  get_audio_frame_size’ :
  /home/dimka/work/suzy/tmp/ffmpeg-android/ffmpeg/libavformat/utils.c:766 :
  undefined reference to

  av_get_bits_per_sample'
 /home/dimka/src/mobile/android/ffmpegtest/obj/local/armeabi/libavformat.a(utils.o):
 In function
 

  ff_interleave_add_packet’ :
  /home/dimka/work/suzy/tmp/ffmpeg-android/ffmpeg/libavformat/utils.c:2909 :
  undefined reference to `av_dup_packet’

  and so on...

  I fail to figure why this is happening. I tried running ndk-build V=1 to check the actual linking command, and libavcodec is sitting there perfectly right, like it should. All other ffmpeg libs are there too.

  Any hints ?

• Why JPEG compressing an uncompressed image differs its original (FFmpeg, NvJPEG, ...)

  22 juin 2021, par Fruchtzwerg

  I am currently struggling to understand why recompressing an uncompressed JPEG image differs its original.

  


  It's clear, that JPEG is a lossy compression, but what if the image to compress is already uncompressed, which means all sampling losses are already included ? In other words : Downsampling and DCT should be inversable at this point without loosing data.

  


  

  


  To make sure losses are not effected by the color space conversion, this step is skipped and YUV images are used.

  


  

  1. Compress YUV image to JPEG (image.yuv —> image.yuv.jpg)

  


  2. Uncompress JPEG image to YUV image (image.yuv.jpg —> image.yuv.jpg.yuv)

  


  3. Compress YUV image to JPEG (image.yuv.jpg.yuv —> image.yuv.jpg.yuv.jpg)

  


  4. Uncompress JPEG image to YUV image (image.yuv.jpg.yuv.jpg —> image.yuv.jpg.yuv.jpg.yuv)

  


  


  Step 1 includes a lossy compression, so we will not deal with this step anymore. For me, intresting is what happens afterwards :

  


  Uncompressing the JPEG image back to YUV (step 2) leads to an image which perfectly fits all sampling steps if compressed again (step 3). So the JPEG image after step 3 should (from my understanding) be exactly the same as after step 1. Also the YUV images after step 4 and step 2 should equal each other.

  


  Looking at the steps for one 8x8 block the following simplified sequence should illustrate what I am trying to descibe. Lets start with the original YUV image, which can only be decompressed loosing all decimal places :

  


  [ 1.123, 2.345, 3.456, ... ]    (YUV)
    DTC + Quantization
[ -26, -3, -6, ... ]            (Quantized frequency space)
    Inverse DTC + Quantization
[ 1, 2, 3, ... ]                (YUV)


  


  Doing this with input, which already matches all steps, which may lead to loss of data afterwards (using round numbers in my example), the decompressed image should match its original :

  


  [ 1, 2, 3, ... ]                (YUV)
    DTC + Quantization
[ -26, -3, -6, ... ]            (Quantized frequency space)
    Inverse DTC + Quantization
[ 1, 2, 3, ... ]                (YUV)


  


  There are also some sources and discussions, which are confirming my idea :

  


  

  • need help creating Jpeg Generational Degradation code

  


  • What factors cause or prevent “generational loss” when JPEGs are recompressed multiple times ?

  


  • Lossless Chroma Subampling

  


  


  So much for theory. In praxis, I've runned these steps using ffmpeg and Nvidias jpeg samples (using NvJPEGEncoder).

  


  ffmpeg :

  


  #Create YUV image
ffmpeg -y -i image.jpg -s 1920x1080 -pix_fmt yuv420p image.yuv
#YUV to JPEG
ffmpeg -y -s 1920x1080 -pix_fmt yuv420p -i image.yuv image.yuv.jpg
#JPEG TO YUV
ffmpeg -y -i image.yuv.jpg -s 1920x1080 -pix_fmt yuv420p image.yuv.jpg.yuv
#YUV to JPEG
ffmpeg -y -s 1920x1080 -pix_fmt yuv420p -i image.yuv.jpg.yuv image.yuv.jpg.yuv.jpg
#JPEG TO YUV
ffmpeg -y -i image.yuv.jpg.yuv.jpg -s 1920x1080 -pix_fmt yuv420p image.yuv.jpg.yuv.jpg.yuv
#YUV to JPEG
ffmpeg -y -s 1920x1080 -pix_fmt yuv420p -i image.yuv.jpg.yuv.jpg.yuv image.yuv.jpg.yuv.jpg.yuv.jpg


  


  Nvidia :

  


  #Create YUV image
./jpeg_decode num_files 1 image.jpg image.yuv
#YUV to JPEG
./jpeg_encode image.yuv 1920 1080 image.yuv.jpg
#JPEG TO YUV
./jpeg_decode num_files 1 image.yuv.jpg image.yuv.jpg.yuv
#YUV to JPEG
./jpeg_encode image.yuv.jpg.yuv 1920 1080 image.yuv.jpg.yuv.jpg
#JPEG TO YUV
./jpeg_decode num_files 1 image.yuv.jpg.yuv.jpg image.yuv.jpg.yuv.jpg.yuv
#YUV to JPEG
./jpeg_encode image.yuv.jpg.yuv.jpg.yuv 1920 1080 image.yuv.jpg.yuv.jpg.yuv.jpg


  


  But a comparison of the images

  


  

  • image.yuv.jpg.yuv and image.yuv.jpg.yuv.jpg.yuv

  


  • image.yuv.jpg.yuv.jpg and image.yuv.jpg.yuv.jpg.yuv.jpg

  


  


  showing differences in the files. That brings me to my question why and where the difference gets happen, since from my understanding the files should be equal.