Recherche avancée

Sur d’autres sites (9452)

• avcodec/v4l2_m2m_dec : remove redundant packet and fix double free

  16 juillet 2020, par Andriy Gelman

  avcodec/v4l2_m2m_dec : remove redundant packet and fix double free
  v4l2_receive_frame() uses two packets s->buf_pkt and avpkt. If avpkt
  
  cannot be enqueued, the packet is buffered in s->buf_pkt and enqueued in
  
  the next call. Currently the ownership transfer between the two packets
  
  is not properly handled. A double free occurs if
  
  ff_v4l2_context_enqueue_packet() returns EAGAIN and v4l2_try_start
  
  returns EINVAL.
  In fact, having two AVPackets is not needed and everything can be
  
  handled by s->buf_pkt.
  This commit removes the local avpkt from v4l2_receive_frame(), meaning
  
  that the ownership transfer doesn't need to be handled and the double
  
  free is fixed.
  Signed-off-by : Andriy Gelman <andriy.gelman@gmail.com>
  

  • [DH] libavcodec/v4l2_m2m_dec.c

• Why use sysconf(_SC_NPROCESSORS_CONF) to get the number of CPU cores in x264 ?

  5 novembre 2017, par bknieven

  I find x264 use sysconf(_SC_NPROCESSORS_CONF) instead of sysconf(SC_NPROCESSORS_ONLN) to get the number of CPU cores.

  Here is the code snippet in x264/common/cpu.c :

  ...
  
  #ifdef __ANDROID__
  
      // Android NDK does not expose sched_getaffinity
  
      return sysconf( _SC_NPROCESSORS_CONF );
  
  #else
  
      ...
  
  ....

  And I find the difference between _SC_NPROCESSORS_CONF and _SC_NPROCESSORS_ONLN in this manual :

  sysconf (_SC_NPROCESSORS_CONF) which returns the number of processors
  the operating system configured. But it might be possible for the
  operating system to disable individual processors and so the call
  sysconf (_SC_NPROCESSORS_ONLN) returns the number of processors which
  are currently online (i.e., available).

  I have two questions :

  1. What is the difference between "the number of processors the operating system configured" and "the number of processors which are currently online" ?
  2. Why x264 use _SC_NPROCESSORS_CONF in Android to get the number of CPU cores ?

• FFMPEG : invalid data found when processing input, but same input works in FFPLAY

  20 janvier 2023, par SoerenS

  I have a TCP stream with raw 8-bit image data (1280x720) that I receive and display with FFPLAY without problems, but it´s not possible to process the same input with FFMPEG.

  


  This works :

  


  ffplay -i tcp://127.0.0.1:8485\?listen -f rawvideo -pixel_format gray -video_size 1280x720

  


  But when I try to process the same stream with FFMPEG, it always immediatly returns after the first frame with :

  


  tcp://127.0.0.1:8485\?listen: Invalid data found when processing input

  


  I tried the following commands :

  


  ffmpeg -i tcp://127.0.0.1:8485\?listen -f rawvideo -pixel_format gray -video_size 1280x720
ffmpeg -i tcp://127.0.0.1:8485\?listen -f rawvideo -pixel_format gray -video_size 1280x720 -c:v mjpeg -f mjpeg -qscale 6 test.avi

  


  Same behavior under Windows and Ubuntu. FFMPEG and FFPLAY are from the same set of prebuilt binaries. Version command returns N-107067-g5d5a014199-20220609. Unfortunately I have no access to the code of the stream origin. Any idea about a potential root-cause and what I could try ?