Recherche avancée

Sur d’autres sites (9328)

• FFMPEG with javaCV can't open stream

  29 juin 2015, par rgomes

  I having a strange behavior when testing to get the video Stream of a Mobotix camera, I’m using javaCV 0.11.
  When I set a timeout I can’t open the stream, the stream only open if I don’t set the timeout parameter.

  I verified this behavior with javaCV 0.11 and Java CV 0.11 in version 0.9 and 0.8 it works with the timeout.

  Probably an error of the lib JavaCV or the way I’m using it :P

  My question for the ffmpeg experts is the following :

  When I’m calling :

  avformat_open_input

  the function returns -138

  I called the function av_strerror fir this error code and the function was returned "Error number -138 occurred".

  A description not very useful, can someone tell me what this error means ?

• avcodec/mediacodecdec : add delay_flush option

  6 mars 2018, par Aman Gupta

  avcodec/mediacodecdec : add delay_flush option
  The default behavior of the mediacodec decoder before this commit
  
  was to delay flushes until all pending hardware frames were
  
  returned to the decoder. This was useful for certain types of
  
  applications, but was unexpected behavior for others.
  The new default behavior with this commit is now to execute
  
  flushes immediately to invalidate all pending frames. The old
  
  behavior can be enabled by setting delay_flush=1.
  With the new behavior, video players implementing seek can simply
  
  call flush on the decoder without having to worry about whether
  
  they have one or more mediacodec frames still buffered in their
  
  rendering pipeline. Previously, all these frames had to be
  
  explictly freed (or rendered) before the seek/flush would execute.
  The new behavior matches the behavior of all other lavc decoders,
  
  reducing the amount of special casing required when using the
  
  mediacodec decoder.
  Signed-off-by : Aman Gupta <aman@tmm1.net>
  
  Signed-off-by : Matthieu Bouron <matthieu.bouron@gmail.com>
  

  • [DH] doc/APIchanges
  • [DH] libavcodec/mediacodec.c
  • [DH] libavcodec/mediacodecdec.c
  • [DH] libavcodec/mediacodecdec_common.c
  • [DH] libavcodec/mediacodecdec_common.h
  • [DH] libavcodec/version.h

• Does Apple AS assembler replace certain NEON instructions with equivalent ones on iOS ?

  5 avril 2012, par Yi Wang

  I was trying to use ffmpeg on iOS and was debugging a crash in the optimized arm code. I have discovered that some unsigned (.u16, .u32) instruction have been replaced by signed ones (.i16, .i32). It's easy to see because disassembled instruction on GDB doesn't quite match the source code.

  For example,

  vrshrn.u32 -> vrshrn.i32
  
  vrshrn.u16 -> vrshrn.i16
  
  vadd.u16 -> vadd.i16

  My questions :

  1. Is this behavior correct and expected ? If not, how do we correct it ?
  2. If they are equivalent, why do we nee need the unsigned ones at all ? Is it because that way the code is more explicit ?
  3. Is this behavior expected with other platform's toolkit ? For example, Android's toolkit ? (I have heard Apple's AS is an ancient one)