Recherche avancée

Sur d’autres sites (3619)

• ffmpeg - when scaling, how to keep shapes of people's heads

  19 janvier 2017, par Dave

  Ok, I’m quite familiar with FFMPEG utility in general, and have used it for
  years to cut short snippets from videos, etc. But it’s only in the last
  month that and I decided to learn to use it to transcode with video-filters
  etc. (Before that, I was using other tools such as ’Handbrake’ and ’FreeMake’
  and VLC, etc.)

  For my ffmpeg transcodes, my target output resolution will always be constant, from one transcode run to the next. But the resolution and display aspect-ratio of the input file, from one transcode run to the next, will vary...could be almost any values.
  The input files will never already have black-bars when displayed.

  So, the relevant portion [ i.e. the video-filter(s) part) of my cmd line ] presently is as follows :

  ffmpeg ... -vf "scale=720:406,setsar=1,pad=720:506:0:40:Black" ...

  Also note : I do NOT use the "-aspect" option in the cmd-line. (Maybe I’ll
  need to (???) to solve my issue, but I’m unsure about how that interacts
  with scaling.)

  ( EDIT : Oh, I happen to have chosen that resolution value of 720x406, for
  the image-area (i.e. inside the top/bottom black bars) because it
  has an aspect ratio of 16:9 (Of course, 16:9 ratio is common these days. )

  My cmd always executes cleanly and produces an output file (a WebM, tho I doubt
  that container types and/or vcodec choices matter at all to scaling algorithm issues).

  So the issue/problem that I’m trying to solve is how to prevent any stretching
  in either direction. In other words, a round soccer ball in the input file
  must yield a round ball in the output file ! (NOT oval-shaped in either axis).

  ( Edit #2 : Oh, I forgot to mention that I’m not have the same amount of stretching from one ffmpeg output file to the next. Sometimes there is
  no stretch in my output file, and with some other input file, the
  people are too tall in the output, and some other output file will have
  people are too wide. I’m assuming
  there is some single cmd that will always work for each randomly sized
  input file, WITHOUT having to resort to examining meta-data of each
  input and then having to adjust portions of the needed ffmpeg cmd.
  I assume this because I have used a tool called "FreeMake" that needs
  no such adjustment. When you do a ’scale’ with that program, it asks
  you to choose one of four adjustment-algorithms labeled "original"
  "stretched", "zoom..." and "auto". If I recall correctly, it was the
  "auto" choice that prevented any stretching.)

  The goal of that last filter (i.e. the "pad=720:506:0:40:Black" phrase) is to
  add a black bar of 40 pixels to the top and 60 pixels to the bottom.
  (That filter IS producing the black-bands, as desired. I mention it,
  because I’m unsure whether it could be having any effect on the altered
  shape of the ’round soccer ball’). If the "pad" filter IS part of the
  issue, then maybe I’ll need to make multiple ffmpeg cmds to achieve
  my overall goal (!?!?). [I’d LIKE to be able to do everything in just
  one ffmpeg cmd, as shown.]

  OK ?

  So are there any image-processing and ffmpeg gurus out there that
  know how to fix my problem ?

  TIA...

  Dave

• Input/output error while using ffmpeg with pulse

  2 septembre 2017, par user116522

  i want to record my audio output. Yesterday, i used the following command

  ffmpeg -f pulse -ac 2 -i 1 -c:a libfdk_aac -b:a 192k test4.m4a

  and it was working. But now, i receive the output :

   ffmpeg version N-83415-g012dd8c Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 4.8 (SUSE Linux)
  
    configuration: --enable-gpl --enable-libx264 --enable-libx265 --enable-nonfree --enable-libfdk-aac --enable-libpulse
  
    libavutil      55. 46.100 / 55. 46.100
  
    libavcodec     57. 75.100 / 57. 75.100
  
    libavformat    57. 66.101 / 57. 66.101
  
    libavdevice    57.  2.100 / 57.  2.100
  
    libavfilter     6. 73.100 /  6. 73.100
  
    libswscale      4.  3.101 /  4.  3.101
  
    libswresample   2.  4.100 /  2.  4.100
  
    libpostproc    54.  2.100 / 54.  2.100
  
  1: Input/output error

  The command

  pactl list sources

  says :

  Source #0
  
          State: SUSPENDED
  
          Name: alsa_output.pci-0000_01_00.1.hdmi-stereo.monitor
  
          Description: Monitor of HDA NVidia Digital Stereo (HDMI)
  
          Driver: module-alsa-card.c
  
          Sample Specification: s16le 2ch 44100Hz
  
          Channel Map: front-left,front-right
  
          Owner Module: 6
  
          Mute: no
  
          Volume: front-left: 65536 / 100% / 0,00 dB,   front-right: 65536 / 100% / 0,00 dB
  
                  balance 0,00
  
          Base Volume: 65536 / 100% / 0,00 dB
  
          Monitor of Sink: alsa_output.pci-0000_01_00.1.hdmi-stereo
  
          Latency: 0 usec, configured 0 usec
  
          Flags: DECIBEL_VOLUME LATENCY 
  
          Properties:
  
                  device.description = "Monitor of HDA NVidia Digital Stereo (HDMI)"
  
                  device.class = "monitor"
  
                  alsa.card = "1"
  
                  alsa.card_name = "HDA NVidia"
  
                  alsa.long_card_name = "HDA NVidia at 0xf7080000 irq 17"
  
                  alsa.driver_name = "snd_hda_intel"
  
                  device.bus_path = "pci-0000:01:00.1"
  
                  sysfs.path = "/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1"
  
                  device.bus = "pci"
  
                  device.vendor.id = "10de"
  
                  device.vendor.name = "NVIDIA Corporation"
  
                  device.product.id = "0fb9"
  
                  device.string = "1"
  
                  module-udev-detect.discovered = "1"
  
                  device.icon_name = "audio-card-pci"
  
          Formats:
  
                  pcm

• HTTP : improve performance by reducing forward seeks

  30 janvier 2017, par Joel Cunningham

  HTTP : improve performance by reducing forward seeks
  This commit optimizes HTTP performance by reducing forward seeks, instead
  
  favoring a read-ahead and discard on the current connection (referred to
  
  as a short seek) for seeks that are within a TCP window’s worth of data.
  
  This improves performance because with TCP flow control, a window’s worth
  
  of data will be in the local socket buffer already or in-flight from the
  
  sender once congestion control on the sender is fully utilizing the window.
  Note : this approach doesn’t attempt to differentiate from a newly opened
  
  connection which may not be fully utilizing the window due to congestion
  
  control vs one that is. The receiver can’t get at this information, so we
  
  assume worst case ; that full window is in use (we did advertise it after all)
  
  and that data could be in-flight
  The previous behavior of closing the connection, then opening a new
  
  with a new HTTP range value results in a massive amounts of discarded
  
  and re-sent data when large TCP windows are used.  This has been observed
  
  on MacOS/iOS which starts with an initial window of 256KB and grows up to
  
  1MB depending on the bandwidth-product delay.
  When seeking within a window’s worth of data and we close the connection,
  
  then open a new one within the same window’s worth of data, we discard
  
  from the current offset till the end of the window.  Then on the new
  
  connection the server ends up re-sending the previous data from new
  
  offset till the end of old window.
  Example (assumes full window utilization) :
  TCP window size : 64KB
  
  Position : 32KB
  
  Forward seek position : 40KB
        *                      (Next window)
  
  32KB |--------------| 96KB |---------------| 160KB
  
          *
  
    40KB |---------------| 104KB
  Re-sent amount : 96KB - 40KB = 56KB
  For a real world test example, I have MP4 file of 25MB, which ffplay
  
  only reads 16MB and performs 177 seeks. With current ffmpeg, this results
  
  in 177 HTTP GETs and 73MB worth of TCP data communication.  With this
  
  patch, ffmpeg issues 4 HTTP GETs and 3 seeks for a total of 22MB of TCP data
  
  communication.
  To support this feature, the short seek logic in avio_seek() has been
  
  extended to call a function to get the short seek threshold value.  This
  
  callback has been plumbed to the URLProtocol structure, which now has
  
  infrastructure in HTTP and TCP to get the underlying receiver window size
  
  via SO_RCVBUF.  If the underlying URL and protocol don’t support returning
  
  a short seek threshold, the default s->short_seek_threshold is used
  This feature has been tested on Windows 7 and MacOS/iOS.  Windows support
  
  is slightly complicated by the fact that when TCP window auto-tuning is
  
  enabled, SO_RCVBUF doesn’t report the real window size, but it does if
  
  SO_RCVBUF was manually set (disabling auto-tuning). So we can only use
  
  this optimization on Windows in the later case
  Signed-off-by : Joel Cunningham <joel.cunningham@me.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/avio.c
  • [DH] libavformat/avio.h
  • [DH] libavformat/aviobuf.c
  • [DH] libavformat/http.c
  • [DH] libavformat/tcp.c
  • [DH] libavformat/url.h