Recherche avancée

Sur d’autres sites (5496)

• PyAV : force new framerate while remuxing stream ?

  7 juin 2019, par ToxicFrog

  I have a Python program that receives a sequence of H264 video frames over the network, which I want to display and, optionally, record. The camera records at 30FPS and sends frames as fast as it can, which isn’t consistently 30FPS due to changing network conditions ; sometimes it falls behind and then catches up, and rarely it drops frames entirely.

  The "display" part is easy ; I don’t need to care about timing or stream metadata, just display the frames as fast as they arrive :

  input = av.open(get_video_stream())
  
  for packet in input.demux(video=0):
  
    for frame in packet.decode():
  
      # A bunch of numpy and pygame code here to convert the frame to RGB
  
      # row-major and blit it to the screen

  The "record" part looks like it should be easy :

  input = av.open(get_video_stream())
  
  output = av.open(filename, 'w')
  
  output.add_stream(template=input.streams[0])
  
  for packet in input.demux(video=0):
  
    for frame in packet.decode():
  
      # ...display code...
  
    packet.stream = output.streams[0]
  
    output.mux_one(packet)
  
  output.close()

  And indeed this produces a valid MP4 file containing all the frames, and if I play it back with mplayer -fps 30 it works fine. But that -fps 30 is absolutely required :

  $ ffprobe output.mp4
  
  Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 960x720,
  
                    1277664 kb/s, 12800 fps, 12800 tbr, 12800 tbn, 25600 tbc (default)

  Note that 12,800 frames/second. It should look something like this (produced by calling mencoder -fps 30 and piping the frames into it) :

  $ ffprobe mencoder_test.mp4
  
  Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 960x720,
  
                    2998 kb/s, 30 fps, 30 tbr, 90k tbn, 180k tbc (default)

  Inspecting the packets and frames I get from the input stream, I see :

  stream: time_base=1/1200000
  
  codec: framerate=25 time_base=1/50
  
  packet: dts=None pts=None duration=48000 time_base=1/1200000
  
  frame: dst=None pts=None time=None time_base=1/1200000

  So, the packets and frames don’t have timestamps at all ; they have a time_base which doesn’t match either the timebase that ends up in the final file or the actual framerate of the camera ; the codec has a framrate and timebase that doesn’t match the final file, the camera framerate, or the other video stream metadata !

  The PyAV documentation is all but entirely absent when it comes to issues of timing and framerate, but I have tried manually setting various combinations of stream, packet, and frame time_base, dts, and pts with no success. I can always remux the recorded videos again to get the correct framerate, but I’d rather write video files that are correct in the first place.

  So, how do I get pyAV to remux the video in a way that produces an output that is correctly marked as 30fps ?

• lavu/libm : add erf hack and make dynaudnorm available everywhere

  20 décembre 2015, par Ganesh Ajjanagadde

  lavu/libm : add erf hack and make dynaudnorm available everywhere
  Source code is from Boost :
  
  http://www.boost.org/doc/libs/1_46_1/boost/math/special_functions/erf.hpp
  
  with appropriate modifications for FFmpeg.
  Tested on interval -6 to 6 (beyond which it saturates), NAN, INFINITY
  
  under -fsanitize=undefined on clang to test for possible undefined behavior.
  This function turns out to actually be essentially as accurate and faster than the
  
  libm (GNU/BSD’s/Mac OS X), and I can think of 3 reasons why upstream
  
  does not use this :
  
  1. They are not aware of it.
  
  2. They are concerned about licensing - this applies especially to GNU
  
  libm.
  
  3. They do not know and/or appreciate the benefits of rational
  
  approximations over polynomial approximations. Boost uses them to great
  
  effect, see e.g swr/resample for bessel derived from them, which is also
  
  similarly superior to libm variants.
  First, performance.
  
  sample benchmark (clang -O3, Haswell, GNU/Linux) :
  3e8 values evenly spaced from 0 to 6
  
  time (libm) :
  
  ./test  13.39s user 0.00s system 100% cpu 13.376 total
  
  time (boost based) :
  
  ./test  9.20s user 0.00s system 100% cpu 9.190 total
  Second, accuracy.
  
  1e8 eval pts from 0 to 6
  
  maxdiff (absolute) : 2.2204460492503131e-16
  
  occuring at point where libm erf is correctly rounded, this is not.
  Illustration of superior rounding of this function :
  
  arg : 0.83999999999999997
  
  erf : 0.76514271145499457
  
  boost : 0.76514271145499446
  
  real : 0.76514271145499446
  i.e libm is actually incorrectly rounded. Note that this is clear from :
  
  https://github.com/JuliaLang/openlibm/blob/master/src/s_erf.c (the Sun
  
  implementation used by both BSD and GNU libm’s), where only 1 ulp is
  
  guaranteed.
  Reasons it is not easy/worthwhile to create a "correctly rounded"
  
  variant of this function (i.e 0.5ulp) :
  
  1. Upstream libm’s don’t do it anyway, so we can’t guarantee this unless
  
  we force this implementation on all platforms. This is not easy, as the
  
  linker would complain unless measures are taken.
  
  2. Nothing in FFmpeg cares or can care about such things, due to the
  
  above and FFmpeg’s nature.
  
  3. Creating a correctly rounded function will in practice need some use of long
  
  double/fma. long double, although C89/C90, unfortunately has problems on
  
  ppc. This needs fixing of toolchain flags/configure. In any case this
  
  will be slower for miniscule gain.
  Reviewed-by : James Almer <jamrial@gmail.com>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] configure
  • [DH] libavutil/libm.h

• fate/cbs : simplify the filter_unit discard tests

  30 juin 2023, par James Almer

  fate/cbs : simplify the filter_unit discard tests
  No need to generate intermediate files and probe them. We only care to know that the
  
  output of the bsf excludes the frames in question, and a simple checksum is enough.
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] tests/fate/cbs.mak
  • [DH] tests/ref/fate/cbs-h264-discard-bidir
  • [DH] tests/ref/fate/cbs-h264-discard-nonintra
  • [DH] tests/ref/fate/cbs-h264-discard-nonkey
  • [DH] tests/ref/fate/cbs-h264-discard-nonref
  • [DH] tests/ref/fate/cbs-hevc-discard-bidir
  • [DH] tests/ref/fate/cbs-hevc-discard-nonintra
  • [DH] tests/ref/fate/cbs-hevc-discard-nonkey
  • [DH] tests/ref/fate/cbs-hevc-discard-nonref