Sur d’autres sites (4280)

• swresample/resample : speed up build_filter by 50%

  4 novembre 2015, par Ganesh Ajjanagadde

  swresample/resample : speed up build_filter by 50%
  This speeds up build_filter by 50%. This gain should be pretty
  
  consistent across all architectures and platforms.
  Essentially, this relies on a observation that the filters have some
  
  even/odd symmetry that may be exploited during the construction of the
  
  polyphase filter bank. In particular, phases (scaled to [0, 1]) in [0.5, 1] are
  
  easily derived from [0, 0.5] and expensive reevaluation of function
  
  points are unnecessary. This requires some rather annoying even/odd
  
  bookkeeping as can be seen from the patch.
  I vaguely recall from signal processing theory more general symmetries allowing even greater
  
  optimization of the construction. At a high level, "even functions"
  
  correspond to 2, and one can imagine variations. Nevertheless, for the sake
  
  of some generality and because of existing filters, this is all that is
  
  being exploited.
  Currently, this patch relies on phase_count being even or (trivially) 1,
  
  though this is not an inherent limitation to the approach. This
  
  assumption is safe as phase_count is 1 << phase_bits, and is hence a
  
  power of two. There is no way for user API to set it to a nontrivial odd
  
  number. This assumption has been placed as an assert in the code.
  To repeat, this assumes even symmetry of the filters, which is the most common
  
  way to get generalized linear phase anyway and is true of all currently
  
  supported filters.
  As a side note, accuracy should be identical or perhaps slightly better
  
  due to this "forcing" filter symmetries leading to a better phase
  
  characteristic. As before, I can’t test this claim easily, though it may
  
  be of interest.
  Patch tested with FATE.
  Sample benchmark (x86-64, Haswell, GNU/Linux) :
  test : swr-resample-dblp-44100-2626
  new :
  
  527376779 decicycles in build_filter(loop 1000),     256 runs,      0 skips
  
  524361765 decicycles in build_filter(loop 1000),     512 runs,      0 skips
  
  516552574 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
  old :
  
  974178658 decicycles in build_filter(loop 1000),     256 runs,      0 skips
  
  972794408 decicycles in build_filter(loop 1000),     512 runs,      0 skips
  
  954350046 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
  Note that lower level optimizations are entirely possible, I focussed on
  
  getting the high level semantics correct. In any case, this should
  
  provide a good foundation.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libswresample/resample.c

• Error recording an RTSP stream without transcoding

  23 août 2017, par Matt

  I’m trying to use FFmpeg to record RTSP streams from several security cameras. I have been successfully transcoding each stream for months now, but since this requires considerable CPU power, I’d like to simply copy each stream to disk in it’s original H.264 format.

  Whenever I try this, I receive and error similar to this (the "current" value varies) :

  Non-monotonous DTS in output stream 0:0 ; previous : 0, current : -62743 ;

  I’ve stripped most of the options I was using, although I really do want to keep -xerror so that FFmpeg quits when it encounters an error :

  ffmpeg.exe -xerror -i rtsp://admin:admin@192.168.1.135 -an -vcodec copy test.mp4

  And I still get this :

      ffmpeg version 3.3.3 Copyright (c) 2000-2017 the FFmpeg developers  
      built with gcc 7.1.0 (GCC)   
      configuration : —enable-gpl
      —enable-version3 —enable-cuda —enable-cuvid —enable-d3d11va —enable-dxva2 —enable-libmfx —enable-nvenc —enable-avisynth —enable-bzlib —enable-fontconfig —enable-frei0r —enable-gnutls —enable-iconv —enable-libass —enable-libbluray —enable-libbs2b —enable-libcaca —enable-libfreetype —enable-libgme —enable-libgsm —enable-libilbc —enable-libmodplug —enable-libmp3lame —enable-libopencore-amrnb —enable-libopencore-amrwb —enable-libopenh264 —enable-libopenjpeg —enable-libopus —enable-librtmp —enable-libsnappy —enable-libsoxr —enable-libspeex —enable-libtheora —enable-libtwolame —enable-libvidstab —enable-libvo-amrwbenc —enable-libvorbis —enable-libvpx —enable-libwavpack —enable-libwebp —enable-libx264 —enable-libx265 —enable-libxavs —enable-libxvid —enable-libzimg —enable-lzma —enable-zlib   
      libavutil      55. 58.100 / 55. 58.100   
      libavcodec     57. 89.100 / 57. 89.100   
      libavformat    57. 71.100 / 57. 71.100   
      libavdevice    57.  6.100 / 57.  6.100   
      libavfilter     6. 82.100 / 6. 82.100   
      libswscale      4.  6.100 / 4.  6.100  
      libswresample   2.  7.100 / 2.  7.100   
      libpostproc    54.  5.100 / 54.  5.100
      [udp @ 0000000002533b60] ’circular_buffer_size’ option was set but it is not supported on this build (pthread support is required) 
      [udp @ 0000000000ec97a0] ’circular_buffer_size’ option was set but it is not supported on this build (pthread support is required) 
      Input #0, rtsp, from ’rtsp ://admin:admin@192.168.1.135’ :   Metadata :
          title : RTSP Session/2.0   Duration : N/A, start : 0.837144, bitrate : N/A
          Stream #0:0 : Video : h264 (High), yuvj420p(pc, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 7 fps, 25 tbr, 90k tbn, 14 tbc Output
      #0, mp4, to ’test.mp4’ :   Metadata :
          title : RTSP Session/2.0
      y    encoder : Lavf57.71.100
          Stream #0:0 : Video : h264 (High) ([33][0][0][0] / 0x0021), yuvj420p(pc, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 7 fps, 25 tbr, 90k tbn, 90k tbc 
      Stream mapping :   Stream #0:0 -> #0:0 (copy) 
      Press [q] to stop, [?] for help
      [mp4 @ 00000000036b8340] Non-monotonous DTS in output stream 0:0 ; previous : 0, current : -62743 ; aborting.
      Conversion failed !
  

  Can anyone explain what the problem is and/or suggest the appropriate flags to handle this ?

• Hacking the Popcorn Hour C-200

  3 mai 2010, par Mans — Hardware, MIPS

  Update : A new firmware version has been released since the publication of this article. I do not know if the procedure described below will work with the new version.

  The Popcorn Hour C-200 is a Linux-based media player with impressive specifications. At its heart is a Sigma Designs SMP8643 system on chip with a 667MHz MIPS 74Kf as main CPU, several co-processors, and 512MB of DRAM attached. Gigabit Ethernet, SATA, and USB provide connectivity with the world around it. With a modest $299 on the price tag, the temptation to repurpose the unit as a low-power server or cheap development board is hard to resist. This article shows how such a conversion can be achieved.
  

  Kernel

  The PCH runs a patched Linux 2.6.22.19 kernel. A source tarball is available from the manufacturer. This contains the sources with Sigma support patches, Con Kolivas’ patch set (scheduler tweaks), and assorted unrelated changes. Properly split patches are unfortunately not available. I have created a reduced patch against vanilla 2.6.22.19 with only Sigma-specific changes, available here.

  The installed kernel has a number of features disabled, notably PTY support and oprofile. We will use kexec to load a more friendly one.

  As might be expected, the PCH kernel does not have kexec support enabled. It does however, by virtue of using closed-source components, support module loading. This lets us turn kexec into a module and load it. A patch for this is available here. To build the module, apply the patch to the PCH sources and build using this configuration. This will produce two modules, kexec.ko and mips_kexec.ko. No other products of this build will be needed.

  The replacement kernel can be built from the PCH sources or, if one prefers, from vanilla 2.6.22.19 with the Sigma-only patch. For the latter case, this config provides a minimal starting point suitable for NFS-root.

  When configuring the kernel, make sure CONFIG_TANGOX_IGNORE_CMDLINE is enabled. Otherwise the command line will be overridden by a useless one stored in flash. A good command line can be set with CONFIG_CMDLINE (under “Kernel hacking” in menuconfig) or passed from kexec.

  Taking control

  In order to load our kexec module, we must first gain root privileges on the PCH, and here a few features of the system are working to our advantage :

  1. The PCH allows mounting any NFS export to access media files stored there.
  2. There is an HTTP server running. As root.
  3. This HTTP server can be readily instructed to fetch files from an NFS mount.
  4. Files with a name ending in .cgi are executed. As root.

  All we need do to profit from this is place the kexec modules, the kexec userspace tools, and a simple script on an NFS export. Once this is done, and the mount point configured on the PCH, a simple HTTP request will send the old kernel screaming to /dev/null, our shiny new kernel taking its place.

  The rootfs

  A kernel is mostly useless without a root filesystem containing tools and applications. A number of tools for cross-compiling a full system exist, each with its strengths and weaknesses. The only thing to look out for is the version of kernel headers used (usually a linux-headers package). As we will be running an old kernel, chances are the default version is too recent. Other than this, everything should be by the book.

  Assembling the parts

  Having gathered all the pieces, it is now time to assemble the hack. The following steps are suitable for an NFS-root system. Adaptation to a disk-based system is left as an exercise.

  1. Build a rootfs for MIPS 74Kf little endian. Make sure kernel headers used are no more recent than 2.6.22.x. Include a recent version of the kexec userspace tools.
  2. Fetch and unpack the PCH kernel sources.
  3. Apply the modular kexec patch.
  4. Using this config, build the modules and install them as usual to the rootfs. The version string must be 2.6.22.19-19-4.
  5. From either the same kernel sources or plain 2.6.22.19 with Sigma patches, build a vmlinux and (optionally) modules using this config. Modify the compiled-in command line to point to the correct rootfs. Set the version string to something other than in the previous step.
  6. Copy vmlinux to any directory in the rootfs.
  7. Copy kexec.sh and kexec.cgi to the same directory as vmlinux.
  8. Export the rootfs over NFS with full read/write permissions for the PCH.
  9. Power on the PCH, and update to latest firmware.
  10. Configure an NFS mount of the rootfs.
  11. Navigate to the rootfs in the PCH UI. A directory listing of bin, dev, etc. should be displayed.
  12. On the host system, run the kexec.sh script with the target hostname or IP address as argument.
  13. If all goes well, the new kernel will boot and mount the rootfs.

  Serial console

  A serial console is indispensable for solving boot problems. The PCH board has two UART connectors. We will use the one labeled UART0. The pinout is as follows (not standard PC pinout).

          +-----------+
         2| * * * * * |10
         1| * * * * * |9
          -----------+
            J7 UART0
      /---------------------/ board edge
  

  Pin	Function
  1	+5V
  5	Rx
  6	Tx
  10	GND

  The signals are 3.3V so a converter, e.g. MAX202, is required for connecting this to a PC serial port. The default port settings are 115200 bps 8n1.