Recherche avancée

Sur d’autres sites (11041)

• configure : fix build issue of vf_dnn_processing.c when —disable-swscale

  2 avril 2020, par Guo, Yejun

  configure : fix build issue of vf_dnn_processing.c when —disable-swscale
  vf_dnn_processing.c recently changed to use swscale to trasfer data
  
  between AVFrame and dnn model.
  Signed-off-by : Guo, Yejun <yejun.guo@intel.com>
  
  Signed-off-by : Linjie Fu <linjie.fu@intel.com>
  

  • [DH] configure

• Android apk file too big when using FFMPeg encoder library

  9 novembre 2022, par Diego Perez

  I'm developing an app which creates x264 videos with the following library :

  



  com.arthenica:mobile-ffmpeg-full:4.2.2.LTS


  



  but the result apk file is too big ( 71mb), so I tried :

  



  com.arthenica:mobile-ffmpeg-min-gpl:4.2.2.LTS


  



  and this way, as the library downloads only a few codecs -included the ones I need- apk size was reduced to 49mb, what is much better, but still looks too big to me, so I'd need to know if any of you know a better way to reduce apk size, because people generally refuse to download such big apps

  



  Regarding the rest of the app (drawables, resources and so) they're well optimized, because if I remove this library and rebuild, the size of the app drops to 10mb

  



  I was reading this question :
FFMPEG Android Library Increase Size

  



  and user S.R suggests to compress all cpu architecture models in one archive file and extract target cpu lib based on cpu model on app's directory and load ffmpeg from there, but I really don't know how to do that.

  



  I'm checking my app's folder structure and noticed there are this next folders regarding ffmpeg lib :

  



  arm64-v8a => ~16mb
armeabi-v7a => ~29mb
x86 => ~17mb
x86_64 => ~21mb


  



  But not sure if I could remove any of them, and as you can see armeabi-v7a is the largest.

  



  

  


• FFmpeg truncates untrunc'ed video

  18 mars 2020, par petrpulc

  Background : Colleague's Panasonic consumer camera had issues with high-capacity SD card and yielded two different types of truncated files (mp4 and mdt) with both header and index corrupted. Both were "fixable" with following steps :

  



  

  1. Locate with hex editor the ascii sequence "mdat" in both a truncated and a corresponding known good file. In mp4 the "mdat" is quite deep in the file as it contains some (but bad) headers, the mdt type almost starts with it.

  


  2. Replace everything up to the "mdat" sequence with known good header. BUT this also means that metadata on length are copied over.

  


  3. Run https://github.com/ponchio/untrunc on the file with corrected header (it refused to run on original files).

  


  4. Profit ! VLC plays the file fine, ffprobe shows correct length. BUT ffmpeg encoding stops at the end timecode of the file I taken the known good header from in step 2.

  


  5. A somewhat ugly solution is to recode the file in VLC (video copy seems to be breaking file up again).

  


  



  I am wondering if I overlooked something ; big time. I guess I do, but simple timecode operations on input file do not seem to have any effect at all.

  



  Is there a way to persuade ffmpeg to encode the whole file that ffprobe and VLC see ?

  



  Files may be provided for analysis on personal basis only, sorry.