Recherche avancée

Sur d’autres sites (11333)

• avformat/mov : add option max_stts_delta

  27 novembre 2021, par Gyan Doshi

  avformat/mov : add option max_stts_delta
  Very high stts sample deltas may occasionally be intended but usually
  
  they are written in error or used to store a negative value for dts correction
  
  when treated as signed 32-bit integers.
  This option lets the user set an upper limit, beyond which the delta is clamped to 1.
  
  Values greater than the limit if negative when cast to int32 are used to adjust onward dts.
  Unit is the track time scale. Default is UINT_MAX - 48000*10 which
  
  allows upto a 10 second dts correction for 48 kHz audio streams while
  
  accommodating 99.9% of uint32 range.
  Signed-off-by : Gyan Doshi <ffmpeg@gyani.pro>
  
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] doc/demuxers.texi
  • [DH] libavformat/isom.h
  • [DH] libavformat/mov.c

• CGO : How do you use pointers in Golang to access data from an array in C

  23 avril 2018, par nevernew

  I’m writing an app for the windows platform using FFmpeg and it’s golang wrapper goav, but I’m having trouble understanding how to use the C pointers to gain access to the data array they point to.

  I’m trying to get the data stored in the AVFrame class and use Go to write it to a file, and eventually a texture in OpenGl to make a video player with cool transitions.

  I think understanding how to cast and access the C data will make coding this a lot easier.

  I’ve stripped out all the relevant parts of the C code, the wrapper and my code, shown below :

  C code - libavutil/frame.h

  #include 
  
  
  
  typedef struct AVFrame {
  
  #define AV_NUM_DATA_POINTERS 8
  
      uint8_t *data[AV_NUM_DATA_POINTERS];
  
  }

  Golang goav wrapper - I don’t really know whats going on here with the unsafe.Pointers and casting but it gives me access to the underlying C code

  package avutil
  
  
  
  /*
  
      #cgo pkg-config: libavutil
  
      #include <libavutil></libavutil>frame.h>
  
      #include 
  
  */
  
  import "C"
  
  import (
  
      "unsafe"
  
  )
  
  
  
  type Frame C.struct_AVFrame
  
  
  
  func AvFrameAlloc() *Frame {
  
      return (*Frame)(unsafe.Pointer(C.av_frame_alloc()))
  
  }
  
  
  
  func Data(f *Frame) *uint8 {
  
      return (*uint8)(unsafe.Pointer((*C.uint8_t)(unsafe.Pointer(&amp;f.data))))
  
  }

  My Golang code

  package main
  
  
  
  import "github.com/giorgisio/goav/avutil"
  
  
  
  func main() {
  
      videoFrame := avutil.AvFrameAlloc()
  
  
  
      data := avutil.Data(videoFrame)
  
  
  
      fmt.Println(data) // here i want the values from data[0] to data[7], but how?
  
  }

• avutil/libm : correct isnan, isinf compat hacks

  15 novembre 2015, par Ganesh Ajjanagadde

  avutil/libm : correct isnan, isinf compat hacks
  isnan and isinf are actually macros as per the standard. In particular,
  
  the existing implementation has incorrect signature. Furthermore, this
  
  results in undefined behavior for e.g double values outside float range
  
  as per the standard.
  This patch corrects the undefined behavior for all usage within FFmpeg.
  Note that long double is not handled as it is not used in FFmpeg.
  
  Furthermore, even if at some point long double gets used, it is likely
  
  not needed to modify the macro in practice for usage in FFmpeg. See
  
  below for analysis.
  Getting long double to work strictly per the spec is significantly harder
  
  since a long double may be an IEEE 128 bit quad (very rare), 80 bit
  
  extended precision value (on GCC/Clang), or simply double (on recent Microsoft).
  
  On the other hand, any potential future usage of long double is likely
  
  for precision (when a platform offers extra precision) and not for range, since
  
  the range anyway varies and is not as portable as IEEE 754 single/double
  
  precision. In such cases, the implicit cast to a double is well defined
  
  and isinf and isnan should work as intended.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavutil/libm.h