Recherche avancée

Sur d’autres sites (5845)

• Building x264 with YASM : failing the ASM check

  11 janvier 2020, par radiofreemyourenji

  My question up front is, "I have new yasm, I think x264 is supposed to be cool with that, why is x264 not cool with that ?"

  For reasons, I am building a CentOS docker image (based on centos:latest) that contains a from-scratch ffmpeg build, following the guide here. It’s a good guide, it’s worked for me before, so I was feeling good about it.

  Today I’m hitting a choke point on the libx264 build point : specifically, I say

  PKG_CONFIG_PATH="/tmp/ffmpeg_build/lib/pkgconfig" \
  
    ./configure \
  
    --prefix="/tmp/ffmpeg_build" \
  
    --bindir="/tmp/bin" \
  
    --enable-static

  And I get a reply back

  Found no assembler

  Minimum version is nasm-2.13

  If you really want to compile without asm, configure with —disable-asm.

  That’s unexpected. I have yasm, which I understand to be 1) there to do the things nasm does but better, and 2) to be the daisy-fresh most modern version given that I pulled it from its repo about an hour ago, and built it about fifty-nine minutes ago. For what it’s worth, nasm is on the box too since the instructions request it, but it’s below their stated version (i.e. it’s "NASM version 2.10.07 compiled on Jun 9 2014")

  So it seems like yasm is not being found. There’s another StackExchange question that mentions that problem, which came out to a pathing issue. So, I added yasm to my path like so :

  PATH=/tmp/ffmpeg_sources/yasm:$PATH \
  
    PKG_CONFIG_PATH="/tmp/ffmpeg_build/lib/pkgconfig" \
  
    ./configure
  
    ...etc

  That still gave the Found-no-assembler problem. As a last, confused resort, I told the script explicitly what I wanted to use for the variable $AS, because based on my quick look into configure, that looked like where yasm/nasm was meant to go. The command becomes :

  AS=`which yasm`
  
    PKG_CONFIG_PATH="/tmp/ffmpeg_build/lib/pkgconfig" \
  
    ./configure
  
    ...etc

  That at least gave

  Found yasm 1.3.0

  Minimum version is nasm-2.13

  If you really want to compile without asm, configure with —disable-asm.

  Looking in the config.log I see the following :

  checking whether /tmp/bin/yasm supports vmovdqa32 [eax]{k1}{z}, zmm0... no
  
  Failed commandline was:
  
  --------------------------------------------------
  
  /tmp/bin/yasm conftest.asm  -I. -I$(SRCPATH) -DARCH_X86_64=1 -I$(SRCPATH)/common/x86/ -f elf64  -o conftest.o
  
  conftest.asm:1: error: instruction expected after label
  
  conftest.asm:1: warning: ignoring unrecognized character `{'
  
  conftest.asm:1: warning: ignoring unrecognized character `}'
  
  conftest.asm:1: warning: ignoring unrecognized character `{'
  
  conftest.asm:1: warning: ignoring unrecognized character `}'
  
  --------------------------------------------------
  
  Failed program was:
  
  --------------------------------------------------
  
  vmovdqa32 [eax]{k1}{z}, zmm0
  
  --------------------------------------------------

  So : what’s the deal here ? Is my assumption that yasm drop-in replaces nasm bad ? Is yasm good for this purpose, but I’m not providing the right information to ./configure ? Are my instructions for building ffmpeg for CentOS simply out of date with respect to this prerequisite and I should just try harder to get a modern nasm ?

• Node.js FFMPEG Reporting Progress Architecture

  11 septembre 2018, par munkee

  I’m running a node.js HTTP server which has a video conversion API built using ffmpeg. I am wondering how best to report on the progress of the file conversion to a separate front end. The HTTP server is going to be standalone as its own service, so I would like to be able to render the percentage complete of the conversion to another server with a simple front end. Upon completion of the conversion the file is downloaded automatically.

  My current end point /convert takes a file URL with a .mov extension, downloads the file and runs it through the conversion process to only output Audio. Using response headers I force the browser to download the file once the conversion has ended, I also delete the temporary file once download has completed.

  A full request would look like

  https://www.someurl.com/convert?file=https://www.filetodownload.com/Skating.mov

  I am using the fluent-ffmpeg npm package : https://github.com/fluent-ffmpeg/node-fluent-ffmpeg which serves a "progress" event :

  ffmpeg('/path/to/file.avi')
  
    .on('progress', function(progress) {
  
      console.log('Processing: ' + progress.percent + '% done');
  
    });

  I am thinking of emitting the progress.percent information on to a separate endpoint maybe along the lines of :

  https://www.someurl.com/progress

  Which will simply be my http server sending the percentage back to the browser. I feel as though I am going about the architecture incorrectly and there must be a better way of architecting the final outcome.

• FFMPEG mp4 input on android

  2 juin 2017, par DweebsUnited

  I have been banging my head against the wall on this for a while now. I need to trim part of an mp4 file, using ffmpeg on android. I have ffmpeg compiled, linked, and I can confirm that it works as expected in my ndk calls. What I am running into is getting an mp4 file to ffmpeg in a protocol it can actually work with.

  Right now, I have a Uri for the file that I get a ParcelFileDescriptor from. I pass its file descriptor to an ndk call that does all the ffmpeg processing using the pipe protocol. Issue : ffmpeg cannot read an mp4 over the pipe protocol, because it needs to seek back to the start once it finds the moov atom.

  All I’m doing is remuxing the videos. I’m not doing any heavy work, or more complicated ffmpeg calls

  Attempted solution : Set up custom AVio calls that open the descriptor as a file stream, and handle it that way. Issue : file descriptor from java is not seekable, it’s more of a stream.

  Possible solution : Preprocess videos to have the moov atom at the front. Issue : Not allowed, the files come from somewhere I cannot control.

  Possible solution : Run one call to find all the file information, then another to actually remux the file. Issue : I don’t know what I need to save from the first parse through to make this possible. Just the moov atom ? Can I just replace the io object in the first call’s inputFormatContext with a new one in the second call ? Can I pass it two distinct file descriptors, both to the same file, and not have to make two ndk calls ?

  Any help or ideas you can offer is greatly appreciated.