Recherche avancée

Sur d’autres sites (7069)

• Keep FFMPEG running and waiting for new image files to encode and stream

  28 janvier 2016, par user2165039

  I am converting TIFF images to HTTP Live Stream. The images are being continuously streamed by a camera and saved to hard drive. FFMPEG is then converting the files to MPEG transport stream (.ts) and segmenting them. However, as soon as FFMPEG runs out of currently saved images to disk, it ends the conversion. Is there a way how I could keep FFMPEG running and waiting for new images to be saved to disk and converting them ?

  This is what I am using :

  ffmpeg -f image2 -r 10/1 -i MMseries_%3d.jpg -c:v libx264 -r 30 -b:v 256000 -flags 
  
      -global_header -map 0 -f segment -segment_time 4 -segment_list_size 0 
  
      -segment_list demo_list.m3u8 -segment_format mpegts video_seg_%05d.ts

• Running FFMPEG commands inside Docker container with Python corrupts video

  15 novembre 2023, par AFortunato

  I have a Docker container running a Python web server. Somewhere in the server, I'm using
asyncio.create_subprocess_shell to run an FFMPEG command that trims and crops a video like :

  


  ffmpeg -ss {start} -to {end} -i {video_path} -vf "crop={width}:{height}:{x_offset}:{y_offset}" -c:a copy -crf 0 -preset ultrafast {output_file}


  


  Whenever I do this with a video with less than 1080p of resolution, everything works great. But if I use HD, 4k etc videos, whatever timestamps I put in start and end, I always get a 1 second video of the last second of the original video.

  


  I'm calling FFMPEG like this

  


  process = await asyncio.create_subprocess_shell(
            command, stdout=asyncio.subprocess.PIPE, stderr=asyncio.subprocess.PIPE
        )


  


  I don't see any errors when running this AND the weird part is that, if I enter the container with
docker exec -it <container> sh</container>

  


  And I run the exact same command in ffmpeg, it works perfectly.

  


  I have no idea what the problem can be, can anyone help me ?

  


• arm : Detect 32 bit cpu features on ARMv8 when running on a 64 bit kernel

  23 juin 2014, par Martin Storsjö

  arm : Detect 32 bit cpu features on ARMv8 when running on a 64 bit kernel
  When running on a 64 bit kernel, /proc/cpuinfo lists different
  
  optional features than on 32 bit kernels (because some of them
  
  are mandatory in the 64 bit implemenations).
  The kernel does list the old features properly if they are queried
  
  via /proc/self/auxv though - however this file is not always readable
  
  (e.g. on most android systems). The getauxval function could also
  
  provide the same info as /proc/self/auxv even if this file isn’t
  
  readable, but this function is not always available (and thus would
  
  need to be loaded with dlsym for compatibility with older android
  
  versions).
  The android cpufeatures library does this slightly differently,
  
  by assuming that these are available if the "CPU architecture"
  
  line is >= 8, see [1] for details.
  It has been suggested to include the old, non-optional features in
  
  /proc/cpuinfo as well, but that suggested patch never was merged.
  
  See [2] for the discussion around this suggestion.
  [1] https://android-review.googlesource.com/91380
  
  [2] http://marc.info/?l=linux-arm-kernel&m=139087240101974
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavutil/arm/cpu.c