Recherche avancée

Sur d’autres sites (9133)

• avcodec/mips/aaccoder_mips : Remove MIPS-specific aaccoder

  15 mars 2024, par Andreas Rheinhardt

  avcodec/mips/aaccoder_mips : Remove MIPS-specific aaccoder
  ff_aac_coder_init_mips() modifies a static const structure of
  
  function pointers. This will crash if the binary uses relro
  
  and is a data race in any case.
  Furthermore it points to a maintainability issue : The
  
  AACCoefficientsEncoder structures have been constified
  
  in commit fd9212f2edfe9b107c3c08ba2df5fd2cba5ab9e3,
  
  a Libav commit merged in 318778de9ebec276cb9dfc65509231ca56590d13.
  
  Libav did not have the MIPS-specific AAC code and so this was
  
  fine for them ; yet FFmpeg had them, but this was not recognized.
  Commit 75a099fc734a4ee2b1347d0a3d8c53d883b95174 points to another
  
  maintainability issue : Contrary to ordinary DSP code, this code
  
  here is way more complex and needs to be constantly kept in sync
  
  with the ordinary code which it mimicks and replaces. Said commit
  
  is the only commit actually changing aaccoder.c in the last few
  
  years and the same change has not been performed for the MIPS
  
  clone ; before that, it even happened several times that the mips
  
  code was broken due to changes of the generic code (see commits
  
  97437bd17a8c5d4135b2f3b1b299bd7bb72ce02c and
  
  de262d018d7d7d9c967af1dfd1b861c4b9eb2a60 or
  
  860dbe0275e57cbf4228f3f653f872ff66ca596b or
  
  933309a6ca0f18bf1d40e917fff455221f57fb4b or
  
  b65ffa316e377213c29736929beba584d0d80d7c). This might even lead
  
  to scenarios where someone changing non-dsp aacenc code would
  
  have to modify mips inline asm in order to keep them in sync.
  
  This is obviously a significant burden (if the AAC encoder were
  
  actively developed).
  Finally, the code does not even compile here due to errors like
  
  "Error : float register should be even, was 1".
  Reviewed-by : Lynne <dev@lynne.ee>
  
  Reviewed-by : Jean-Baptiste Kempf <jb@videolan.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/aacenc.c
  • [DH] libavcodec/aacenc.h
  • [DH] libavcodec/mips/Makefile
  • [DH] libavcodec/mips/aaccoder_mips.c

• lavfi/delogo : use weighted interpolation

  26 juin 2013, par Jean Delvare

  lavfi/delogo : use weighted interpolation
  The original delogo algorithm interpolates both horizontally and
  
  vertically and uses the average to compute the resulting sample. This
  
  works reasonably well when the logo area is almost square. However
  
  when the logo area is significantly larger than high or higher than
  
  large, the result is largely suboptimal.
  The issue can be clearly seen by testing the delogo filter with a fake
  
  logo area that is 200 pixels large and 2 pixels high. Vertical
  
  interpolation gives a very good result in that case, horizontal
  
  interpolation gives a very bad result, and the overall result is poor,
  
  because both are given the same weight.
  Even when the logo is roughly square, the current algorithm gives poor
  
  results on the borders of the logo area, because it always gives
  
  horizontal and vertical interpolations an equal weight, and this is
  
  suboptimal on borders. For example, in the middle of the left hand
  
  side border of the logo, you want to trust the left known point much
  
  more than the right known point (which the current algorithm already
  
  does) but also much more than the top and bottom known points (which
  
  the current algorithm doesn’t do.)
  By properly weighting each known point when computing the value of
  
  each interpolated pixel, the visual result is much better, especially
  
  on borders and/or for high or large logo areas.
  The algorithm I implemented guarantees that the weight of each of the
  
  4 known points directly depends on its distance to the interpolated
  
  point. It is largely inspired from the original algorithm, the key
  
  difference being that it computes the relative weights globally
  
  instead of separating the vertical and horizontal interpolations and
  
  combining them afterward.
  Signed-off-by : Jean Delvare <khali@linux-fr.org>
  
  Signed-off-by : Stefano Sabatini <stefasab@gmail.com>
  

  • [DH] libavfilter/vf_delogo.c
  • [DH] tests/ref/fate/filter-delogo

• Video compressing not working with ffmpeg4android_lib library

  18 décembre 2019, par Nand Kishor Patidar

  When I am trying video compressing with ffmpeg4android_lib library then it is working on debug mode(Not google play store app) after that when I check live on play store the video compressing is not working and found that the application crashed. After the crash, it gives the error :-
  videokitLibPath not exits : /data/app/com.practice.presto-SSicBo_Qm4UXOQAQ45Vttg==/lib/arm/libvideokit.so
  My App Log is below :

  1576657500.663 20809-20809/com.practice.presto D/MyPracticeAudioVideo: outside wifi file type 2
  
  1576657500.807 20809-22043/com.practice.presto D/MyPracticeAudioVideo: Worker started
  
  1576657500.807 20809-22043/com.practice.presto D/MyPracticeAudioVideo: new file video path /storage/emulated/0/DCIM/Camera/VID_20191218_135413.mp4
  
  1576657500.808 20809-22043/com.practice.presto D/MyPracticeAudioVideo: Acquire wake lock
  
  1576657500.812 20809-22043/com.practice.presto I/ffmpeg4android: checkForPermissions() called
  
  1576657500.814 20809-22043/com.practice.presto I/ffmpeg4android: permission already granted
  
  1576657500.830 20809-22043/com.practice.presto D/MyPracticeAudioVideo: ffmpeg -y -i /storage/emulated/0/DCIM/Camera/VID_20191218_135413.mp4 -strict experimental -s 320x240 -r 25 -aspect 4:3 -vcodec mpeg4 -b 150k -ab 48000 -ac 2 -ar 22050 /storage/emulated/0/pp/1576657432247.mp4
  
  1576657500.831 20809-22043/com.practice.presto I/ffmpeg4android: running ffmpeg4android_lib: 41.07.00_LM41_00
  
  1576657500.831 20809-22043/com.practice.presto D/ffmpeg4android: {"ffmpeg","-y","-i","/storage/emulated/0/DCIM/Camera/VID_20191218_135413.mp4","-strict","experimental","-s","320x240","-r","25","-aspect","4:3","-vcodec","mpeg4","-b","150k","-ab","48000","-ac","2","-ar","22050","/storage/emulated/0/pp/1576657432247.mp4"}
  
  1576657500.833 20809-22043/com.practice.presto D/ffmpeg4android: /storage/emulated/0/DCIM/Camera/VID_20191218_135413.mp4 length in bytes: 15793157
  
  1576657500.834 20809-22043/com.practice.presto E/ffmpeg4android: **videokitLibPath not exits: /data/app/com.practice.presto-SSicBo_Qm4UXOQAQ45Vttg==/lib/arm/libvideokit.so**
  
  1576657500.835 20809-22043/com.practice.presto I/Videokit: libvideokit.so load Fail: /data/app/com.practice.presto-SSicBo_Qm4UXOQAQ45Vttg==/lib/arm/libvideokit.so
  
  1576657500.835 20809-22043/com.practice.presto I/Videokit: args is not NULL
  
  1576657500.835 20809-22043/com.practice.presto I/Videokit: more then one arg
  
  1576657500.835 20809-22043/com.practice.presto I/Videokit: function symbol not found
  
  1576657500.835 20809-22043/com.practice.presto D/Videokit: Calling videokit run via loader
  
  1576657500.860 20809-22043/com.practice.presto A/libc: **Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 22043 (Thread-19), pid 20809 (practice.presto)**