Recherche avancée

Sur d’autres sites (13469)

• Documentation #2846 : blocage des notification à cause d’une protection .htaccess

  3 mai 2013, par cedric -

  Je lis que l’on peut faire quelque chose comme
  

  SetEnvIf Request_URI ^spip.php~?action=cron$ bypass=1
  Satisfy any
  Order allow,deny
  
  Allow from env=bypass
  AuthUserFile ...
  
  AuthName ...
  
  AuthType Basic
  
  Require valid-user
  

  A tester

• Why do I get different codecs on Windows and Linux with same code ?

  27 janvier 2016, par user3277340

  I am using the API version of FFMPEG to generate a MP4 file from a series of images. I specify the output by calling

  AVFormatContext *oc = NULL ;
  avformat_alloc_output_context2 (&oc,NULL,"mp4",NULL) ;

  Running the exact same code on Windows and Linux I get different codecs assigned. On Windows, the value of oc->oformat->video_code is AV_CODEC_ID_H264 (28), but on Linux I get AV_CODEC_ID_MPEG4.

  I tracked this down because on Windows my calls to avcodec_encode_video2(.,.,.,&got_packet) were always returning got_packet=0 so I never called av_interleaved_write_frame. I added a NULL AVFrame at the end to flush the video. But it was very small and did not contain the images I expected to see there.

  But on Linux everything worked just fine. So I went ahead and manually changed the value of oc->oformat->video_code and I got the expected results.

  My questions :

  1) Why do I get different codec types on different platforms with the same code ? Is there a parameter I need to set to force MPEG4 ?

  2) Is it "legal" to change this parameter after the call to avformat_alloc_output_context2 ? My concern is that "oc" has been properly initialized and, with the change, something may be inconsistent.

  3) Is there a way to force the MPEG4 codec on any machine ?

  Thanks.

• lavd/v4l2 : produce a 0 byte packet when a dequeued buffer's size is unexpected

  5 juin 2019, par Stephan Hilb

  lavd/v4l2 : produce a 0 byte packet when a dequeued buffer's size is unexpected
  Behave like we do for V4L2_BUF_FLAG_ERROR, implemented in commit 28f20d2ff4 .
  For some devices (probably also related to the V4L driver implementation)
  
  it happens that when invoking the ioctl DQBUF, the returned buffer is not
  
  of the expected size. Here are two examples for such occurrences :
      [video4linux2,v4l2 @ 0x258b440] Dequeued v4l2 buffer contains 609596 bytes, but 614400 were expected. Flags : 0x00000001.
  
      /dev/video1 : Invalid data found when processing input
      [video4linux2,v4l2 @ 0x225f440] Dequeued v4l2 buffer contains 609508 bytes, but 614400 were expected. Flags : 0x00000001.
  
      /dev/video1 : Invalid data found when processing input
  For the ffmpeg CLI tool this means it will stop capturing and exit.
  The described behaviour was observed at least with one OmniVision USB
  
  web cam and with some stk1160 devices.
  If you search the web for the error message, you will find quite a few
  
  instances of this problem. Some of them experienced on other devices.
  Probably fixes ticket #4795
  Signed-off-by : Alexander Strasser <eclipse7@gmx.net>
  

  • [DH] libavdevice/v4l2.c