Recherche avancée

Sur d’autres sites (8652)

• vc2enc : properly promote operations to 64 bits

  13 mars 2018, par Rostislav Pehlivanov

  vc2enc : properly promote operations to 64 bits
  On Windows machines, the UL suffix still means 32 bits.
  
  The only parts that need 64 bits are (1ULL << (m + 32)) and
  
  (t*qf + qf). Hence, use the proper ULL suffix for the former
  
  and just increase the type of the qf constant for the latter.
  
  No overflows can happen as long as these are done in 64 bits and
  
  the quantization table doesn't change.
  Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  

  • [DH] libavcodec/vc2enc.c

• cbs : Don't set AVBuffer's opaque

  29 juillet 2019, par Andreas Rheinhardt

  cbs : Don't set AVBuffer's opaque
  cbs is currently inconsistent regarding the opaque field that can be
  
  used as a special argument to av_buffer_create in order to be used
  
  during freeing the buffer : ff_cbs_alloc_unit_content and all the free
  
  functions used name this parameter as if it should contain a pointer to
  
  the unit whose content is about to be created ; but both
  
  ff_cbs_alloc_unit_content as well as ff_cbs_h264_add_sei_message
  
  actually use a pointer to the CodedBitstreamContext as opaque. It should
  
  actually be neither, because it is unneeded (as is evidenced by the fact
  
  that none of the free functions use this pointer at all) and because it
  
  ties the unit's content to the lifetime of other objects, although a
  
  refcounted buffer is supposed to have its own lifetime that only ends
  
  when its reference count reaches zero. This problem manifests itself in
  
  the pointer becoming dangling.
  
  The pointer to the unit can become dangling if another unit is added to
  
  the fragment later as happens in the bitstream filters ; in this case,
  
  the pointer can point to the wrong unit (if the fragment's unit array
  
  needn't be relocated) or it can point to where the array was earlier.
  
  It can also become dangling if the unit's content is meant to survive
  
  the resetting of the fragment it was originally read with. This applies
  
  to the extradata of H.264 and HEVC.
  
  The pointer to the context can become dangling if the context is closed
  
  before the content is freed. Although this doesn't seem to happen right
  
  now, it could happen, in particular if one uses different
  
  CodedBitstreamContexts for in- and output.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/cbs.c
  • [DH] libavcodec/cbs.h
  • [DH] libavcodec/cbs_av1.c
  • [DH] libavcodec/cbs_h2645.c
  • [DH] libavcodec/cbs_jpeg.c
  • [DH] libavcodec/cbs_mpeg2.c
  • [DH] libavcodec/cbs_vp9.c

• FFMPEG split into two frames with BGR convertion instead of RGB | OpenVino

  26 avril 2020, par Mayur Kanojiya

  

  



  I don't know why this happen because when i pass the normal frames directly, it didnot split into two frames but when i do some post-processing to count the person at 2nd person it flips into 2 frames.

  



  I think flush called or i missed one frame in loop :/

  



  So my question is that How can this is possible as i am directly feeding my frames ?

  



  I used following ffmpeg command to pipe with python.

  



  

  • ffmpeg -v warning -f rawvideo -pixel_format bgr24 -video_size 768x432 -framerate 24 -i - http://0.0.0.0:3004/fac.ffm