Recherche avancée

Sur d’autres sites (6142)

• How can I reset the path of FFMPEG in the VideoExport library in Processing ?

  11 avril 2021, par bella

  Note : This question was originally titled "How can I reset the path of FFMPEG in Java ?" but, as it has been pointed out in the comments and the answer, the issue is not with Java, so I've changed the title to make it easier to find for others with the same issue.

  


  ---

  


  I accidentally set the path for FFMPEG to a different folder, and I can't change it back.

  


  I'm using Processing (the library and its IDE) and the user-created Video Export library to capture and write to an mp4 video file. The library required FFMPEG, so I downloaded and installed it. After I installed it, I ran the code, and the library called Java to request the path of FFMPEG. I wrongly set the path to a different folder (which I eventually deleted), and immediately realized my mistake. I ran the code again to see if I could trigger the prompt again to correct the path.

  


  ---

  


  The console response I received was : (I'm sure most of it doesn't have to do with the actual issue. However, I wanted to show all of it in case it somehow does.)

  


  


  Oct 24, 2016 10:23:25 PM java.util.prefs.WindowsPreferences 
WARNING : Could not open/create prefs root node Software\JavaSoft\Prefs
at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
java.io.IOException : Cannot run program
"C :...\Processing\Octree_Graphics\data\FFMPEG\ff-prompt.bat" :
CreateProcess error=2, The system cannot find the file specified at
java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) at
com.hamoid.VideoExport.startFfmpeg(Unknown Source) at
com.hamoid.VideoExport.initialize(Unknown Source) at
com.hamoid.VideoExport.saveFrame(Unknown Source) at
Octree_Graphics.draw(Octree_Graphics.java:90) at
processing.core.PApplet.handleDraw(PApplet.java:2399) at
processing.opengl.PSurfaceJOGL$DrawListener.display(PSurfaceJOGL.java:731)
at
jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:692)
at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:674)
at
jogamp.opengl.GLAutoDrawableBase$2.run(GLAutoDrawableBase.java:443)
at
jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1293)
at
jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1147)
at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:759) at
com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:81)
at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:452)
at
com.jogamp.opengl.util.FPSAnimator$MainTask.run(FPSAnimator.java:178)
at java.util.TimerThread.mainLoop(Timer.java:555) at
java.util.TimerThread.run(Timer.java:505) Caused by :
java.io.IOException : CreateProcess error=2, The system cannot find the
file specified at java.lang.ProcessImpl.create(Native Method) at
java.lang.ProcessImpl.(ProcessImpl.java:386) at
java.lang.ProcessImpl.start(ProcessImpl.java:137) at
java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) ... 17 more
VideoExport error : Ffmpeg failed. Study
C :...\Processing\Octree_Graphics\basic.mp4.txt for more details.

  


  


  ---

  


  I need to find a way to reset the path of FFMPEG that Java has. I have tried uninstalling and reinstalling the library, but I haven't tried Java (I don't want to mess with anything it has in its current state).

  


• avcodec/aacdec_fixed : Move fixed-point sinewin tables to its only user

  30 décembre 2020, par Andreas Rheinhardt

  avcodec/aacdec_fixed : Move fixed-point sinewin tables to its only user
  The fixed-point AAC decoder is the only user of the fixed-point sinewin
  
  tables from sinewin ; and it only uses a few of them (about 10% when
  
  counting by size). This means that guarding initializing these tables by
  
  an AVOnce (as done in 3719122065863f701026632f610175980d42b05a) is
  
  unnecessary for them. Furthermore the array of pointers to the
  
  individual arrays is also unneeded.
  Therefore this commit moves these tables directly into aacdec_fixed.c ;
  
  this is done by ridding the original sinewin.h and sinewin_tablegen.h
  
  headers completely of any fixed-point code at the cost of a bit of
  
  duplicated code (the alternative is an ugly ifdef-mess).
  This saves about 58KB from the binary when using hardcoded tables (as
  
  these tables are hardcoded in this scenario) ; when not using hardcoded
  
  tables, most of these savings only affect the .bss segment, but the rest
  
  (< 1KB) contains relocations (i.e. savings in .data.rel.ro).
  Reviewed-by : Lynne <dev@lynne.ee>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] configure
  • [DH] libavcodec/Makefile
  • [DH] libavcodec/aac_defines.h
  • [DH] libavcodec/aacdec_fixed.c
  • [DH] libavcodec/aacdec_template.c
  • [DH] libavcodec/sinewin.c
  • [DH] libavcodec/sinewin.h
  • [DH] libavcodec/sinewin_fixed.c
  • [DH] libavcodec/sinewin_fixed_tablegen.c
  • [DH] libavcodec/sinewin_fixed_tablegen.h
  • [DH] libavcodec/sinewin_tablegen.c
  • [DH] libavcodec/sinewin_tablegen.h
  • [DH] libavcodec/sinewin_tablegen_template.c

• FFmpeg capture, mkvtimestamp_v2 and timecode don't play nice

  24 mai 2021, par Bouke

  Trying to capture and modify the TC in-file afterwards.
I've found a nice way to store the timestamps from the capture.
Gyan's brillant filterchain

  


  This works fine using this line :

  


  ffmpeg -hide_banner -f "decklink" -queue_size "1073741824" -raw_format "auto" -format_code "Hi50" -video_input "sdi" -i "bm mini One" -filter_complex "settb=1/1000,setpts=RTCTIME/1000-1500000000000,mpdecimate,split[out][ts];[out]setpts=N/25/TB[out]" -map "[out]" -c:a "copy" -c:v "prores" -profile:v "1" -vendor "ap10" -pix_fmt "yuv422p10le" "/Volumes/Data/tst1.mov" -map "[ts]" -f mkvtimestamp_v2 "/Volumes/Data/time.txt" -vsync 0


  


  But, when I add -timecode "00:00:00:00" (to force a TC atom in the output), horrible things happen.

  


  ffmpeg -f "decklink" -queue_size "1073741824" -raw_format "auto" -format_code "Hi50" -video_input "sdi" -i "bm mini One" -filter_complex "settb=1/1000,setpts=RTCTIME/1000-1500000000000,mpdecimate,split[out][ts];[out]setpts=N/25/TB[out]" -map "[out]" -timecode "00:01:00:00" -c:a "copy" -c:v "prores" -profile:v "1" -vendor "ap10" -pix_fmt "yuv422p10le" "/Volumes/Data/tst1.mov" -map "[ts]" -f mkvtimestamp_v2 "/Volumes/Data/time.txt" -vsync 0


  


  The timecode does not run at the video speed, skips a frame or two here and there, and the image freezes after a random amount of time (between 10 seconds and a minute or so).

  


  How come the timecode can mess up stuff that much ? From what I understand it's just a couple of atoms in the moov atom, and a reference where the actual TC value (as frames) is stored in the mdat.

  


  I highly suspect the -vsync 0 to also work on the video, and I've had issues with that before. If I omit that, the video is fine, the TC is fine, but there is no metadata output, just the # timecode format v2