Recherche avancée

Sur d’autres sites (11989)

• Reduce latency in ffmpeg snapshot

  3 décembre 2015, par Acorian0

  I have a latency problem with FFMPEG.

  I have a streaming server running and I occasionally need to take multiple snapshots over a period of time (in the example below, 5s), and then examine the snapshots taken. Time is critical.

  With this command I take 25 frames per second over 5 seconds, meaning I will have 125 snapshots in my folder.

  ffmpeg.exe -ss 0.05 -re -i udp://239.255.0.xx:xxxx -ss 0 -vf fps=25 -to 5 -y \Test\%5d.jpg

  The -vf fps is forcing the 25 frames per second even if the server can’t provide them.

  The problem is that -ss 0.05 is not doing its job. It is supposed to delay the initial snapshot for 50 milliseconds but FFMPEG takes around 200ms to "start" the service on itself :/. This means the first snapshot is taken after around 200ms after I called the service. (200ms is way too big of a latency for my purpose... I can survive with 100ms)

  How can I force FFMPEG to start taking snapshots earlier ? Or is there a way to get snapshots, let’s say, from the buffer (e.g. start taking snapshots 150ms in the past) ?

  PS : Changing the -ss from 0.05 to 0.00 is not doing anything, I can only see the -ss doing something if the value is bigger than 0.2/0.25. Another thing, using a newer version of FFMPEG is by now impossible

  Sample OUTPUT :

  ffmpeg version 2.4.5 Copyright (c) 2000-2014 the FFmpeg developers
  
    built on Dec 30 2014 14:53:50 with gcc 4.9.2 (GCC)
  
    configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --disable-w32thread
  
  s --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-icon
  
  v --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable
  
  -libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencor
  
  e-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-l
  
  ibschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-li
  
  bvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-l
  
  ibwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --ena
  
  ble-lzma --enable-decklink --enable-zlib
  
    libavutil      54.  7.100 / 54.  7.100
  
    libavcodec     56.  1.100 / 56.  1.100
  
    libavformat    56.  4.101 / 56.  4.101
  
    libavdevice    56.  0.100 / 56.  0.100
  
    libavfilter     5.  1.100 /  5.  1.100
  
    libswscale      3.  0.100 /  3.  0.100
  
    libswresample   1.  1.100 /  1.  1.100
  
    libpostproc    53.  0.100 / 53.  0.100
  
  [mpeg2video @ 01d77120] Invalid frame dimensions 0x0.
  
  Input #0, mpegts, from 'udp://239.255.0.14:5014':
  
    Duration: N/A, start: 159.051978, bitrate: 105241 kb/s
  
    Program 1
  
      Metadata:
  
        service_name    : Service01
  
        service_provider: FFmpeg
  
      Stream #0:0[0x100]: Video: mpeg1video ([2][0][0][0] / 0x0002), yuv420p(tv), 1920x1080 [SAR 1:1 D
  
  AR 16:9], 104857 kb/s, 50 tbr, 90k tbn, 50 tbc
  
      Stream #0:1[0x101]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 384 kb/s
  
  [swscaler @ 01d70060] deprecated pixel format used, make sure you did set range correctly
  
  Output #0, image2, to 'C:\Test\%5d.jpg':
  
    Metadata:
  
      encoder         : Lavf56.4.101
  
      Stream #0:0: Video: mjpeg, yuvj420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25
  
  tbn, 25 tbc
  
      Metadata:
  
        encoder         : Lavc56.1.100 mjpeg
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (mpeg1video (native) -> mjpeg (native))
  
  Press [q] to stop, [?] for help
  
  frame=  125 fps= 25 q=24.8 Lsize=N/A time=00:00:05.00 bitrate=N/A dup=1 drop=0
  
  video:9710kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

• x264 encoding taking longer when encoding static frames (than

  14 septembre 2015, par Danilo

  ​Hi,
  I’m using x264 for live video streaming and I’ve noticed that the thread
  responsible for encoding uses ​​more cpu (sometimes 50% more with 1920x1080) when the video stream is frozen (i.e. : camera is sending the same frame over an over again) or when I make it encode the same image over and over again.

  This seems somewhat counter intuitive to me, as I would expect x264 to use
  more processing power when encoding complex scenes other then static ones.

  My encoder settings are the following :

  1280x720 fps=25/1 timebase=0/0 bitdepth=8 cabac=0 ref=1 deblock=1:0:0 analyse=0x3:0x113
  
  me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
  
  8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 lookahead_threads=0
  
  sliced_threads=0 slice_max_size=1190 nr=60 decimate=1 interlaced=0 bluray_compat=0
  
  constrained_intra=0 bframes=0 weightp=0  keyint=1200 keyint_min=120 scenecut=40
  
  intra_refresh=0 rc_lookahead=0 rc=crf mbtree=0 crf=24.0 qcomp=0.60 qpmin=0 qpmax=69
  
  qpstep=4 vbv_maxrate=1024 vbv_bufsize=350 crf_max=35.0 nal_hrd=none

  I created a github gist based on the example.c encoder bundled in x264’s
  source code and tested encoding times with it. (You can find it here :
  https://gist.github.com/danilogr/ab4976ff4e0831ab274b)

  Average encoding time for the static scene is 38% bigger than for a scene
  with movements. (You can find my test case and also the output from my test
  encoder on the link above).

  ​​
  ​I’ve also noticed that by setting ​​scenecut=0, subme=0, trellis=0 and me=dia I can get rid of this problem​, but with noticeable quality​ decrease.

  ​
  ​Could anyone, please, shed some light on the reasons for this odd behavior ?
  ​Also, what can be done in order to avoid this situation without a major decrease in quality ?​

• avcodec/tiff : do not abort decoding if strips are available

  2 octobre 2020, par Paul B Mahol

  avcodec/tiff : do not abort decoding if strips are available
  Even if such files are invalid, they can be decoded just fine.
  
  Also stored tiles may have bigger dimensions than displayed ones,
  
  so do not abort decoding in such cases.
  

  • [DH] libavcodec/tiff.c