Recherche avancée

Sur d’autres sites (7614)

• avcodec/dovi_rpuenc : add ff_dovi_rpu_generate()

  30 mars 2024, par Niklas Haas

  avcodec/dovi_rpuenc : add ff_dovi_rpu_generate()
  This function takes a decoded AVDOVIMetadata struct and turns it back
  
  into a binary RPU. Verified using existing tools, and matches the
  
  bitstream in official reference files.
  I decided to just roll the EMDF and NAL encapsulation into this function
  
  because the end user will need to do it otherwise anyways.
  

  • [DH] libavcodec/dovi_rpu.h
  • [DH] libavcodec/dovi_rpuenc.c

• ffmpeg encoding slowly, not using much CPU

  30 juin 2012, par eblume

  I am using the latest (as of this post) version of ffmpeg on OS X as installed via homebrew (an OS X 3rd-party package manager with a good reputation.) I am trying to encode video that was recorded using Fraps on another machine to reduce the file size while preserving as much quality as is reasonably possible.

  Fraps records video in a .avi container and I believe does absolutely no encoding - instead, it's just a stream of image files. The resulting files are often enormous, obviously. I want to set up a cron job that finds recorded files and encodes them to H.264 with some sort of audio codec (I'm currently using libmp3lame but will revisit it when I get video working right - will probably switch to a lossless audio codec.)

  My problem is that while encoding seems to be working exactly how I want it - very few compression artifacts but about 5% of the original size - the encoding is taking forever. I'm averaging about 1.5 encoded frames per second, and these are 2-3 hours of 30FPS video. On top of that, my CPU is never fully utilized. On my dual-core CPU I am getting a median usage of about 40% of one core, with occasional peaks of 140% to 160%.

  So the question is : How can I speed up encoding ? I'm sure there's got to be some options I'm missing out on.

  Here's the command I use :

  ffmpeg -i INFILE -c copy -c:a libmp3lame -ar 44100 -q:a 5 \
  
                -threads 0 -c:v libx264 OUTFILE

  Thanks !

  EDIT : Actually, it looks like this command isn't compressing that well either - I'll do some digging but it seems that this might be being too generous with the bitrate for H.264. At first I was getting around 2Mb/s but it's gone up to almost 20Mb/s - looks like I'm basically not compressing at all.

• Swapping FFMPEG input source

  21 novembre 2017, par stevendesu

  I’m using FFMPEG to stream RMTP to a server. I wish to change what I’m streaming without breaking the connection to this server.

  My current FFMPEG command looks like so :

  ffmpeg -f v4l2 -s 1280x720 -r 10 -i /dev/video0 -c:v libx264 -f flv -r 30 -pix_fmt yuv420p "rtmp://server live=true pubUser=user pubPasswd=pass playpath=stream"

  If I wanted to change from /dev/video0 to /dev/video1 then I need to stop this program and re-run the command swapping out the -i bit.

  Since FFMPEG can read from stdin as well as files, I believe it should be possible to switch the input source on the fly by either piping the output of a different program, or utilizing UNIX sockets. There may also be a solution built into FFMPEG which I’m not aware of.

  My question now is : what’s the simplest / least code / most recommended way of switching these inputs ? Is there a third-party tool that’s recommended ? Does FFMPEG have an alternate command-line parameter I’ve never heard of ? If I do use a UNIX socket of stdin, is there a recommended way to change what’s being written to them ?

  One of my concerns is that if I have FFMPEG read in from a UNIX socket and in a separate shell I have a different instance of FFMPEG writing to this UNIX socket, during the brief period when I’m switching sources the first instance of FFMPEG (which is doing the broadcasting) would die, as it couldn’t find any video data to stream.