Recherche avancée

Sur d’autres sites (2627)

• Android Camera Video frames decoding coming out distorted with horizontal lines

  13 novembre 2018, par Iain Stanford

  I’ve been porting over the following Test Android example to run in a simple Xamarin Android project.

  https://bigflake.com/mediacodec/ExtractMpegFramesTest_egl14.java.txt

  I’m running a video captured by the camera (on the same device) through this pipeline but the PNGs I’m getting out the other end are distorted, I assume due to the minefield of Android Camera color spaces.

  Here are the images I’m getting running a Camera Video through the pipeline...

  https://imgur.com/a/nrOVBPk

  Its hard to tell, but it ’kinda’ looks like it is a single line of the actual image, stretched across. But I honestly wouldn’t want to bank on that being the issue as it could be a red herring.

  However, when I run a ’normal’ video that I grabbed online through the same pipeline, it works completely fine.

  I used the first video found on here (the lego one) http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5

  And I get frames like this...

  https://imgur.com/a/yV2vMMd

  Checking out some of the ffmpeg probe data of the video, both this and my camera video have the same pixel format (pix_fmt=yuv420p) but there are differences in color_range.

  The video that works has,

  color_range=tv
  
  color_space=bt709
  
  color_transfer=bt709
  
  color_primaries=bt709

  And the camera video just has...

  color_range=unknown
  
  color_space=unknown
  
  color_transfer=unknown
  
  color_primaries=unknown

  The media format of the camera video appears to be in SemiPlanar YUV, the codec output gets updated to that at least. I get an OutputBuffersChanged message which sets the output buffer of the MediaCodec to the following,

  {
  
      mime=video/raw,
  
      crop-top=0, 
  
      crop-right=639, 
  
      slice-height=480,
  
      color-format=21,
  
      height=480, 
  
      width=640, 
  
      what=1869968451, 
  
      crop-bottom=479, 
  
      crop-left=0, 
  
      stride=640
  
  }

  I can also point the codec output to a TextureView as opposed to OpenGL surface, and just grab the Bitmap that way (obviously slower) and these frames look fine. So maybe its the OpenGL display of the raw codec output ? Does Android TextureView do its on decoding ?

  Note - The reason I’m looking into all this is I have a need to try and run some form of image processing on a raw camera feed at as close to 30fps as possible. Obviously, this is not possible some devices, but recording a video at 30fps and then processing the video after the fact is a possible workaround I’m investigating. I’d rather try and process the image in OpenGL for the improved speed than taking each frame as a Bitmap from the TextureView output.

  In researching this I’ve seen someone else with pretty much the exact same issue here How to properly save frames from mp4 as png files using ExtractMpegFrames.java ?
  although he didn’t seem to have much luck finding out what might be going wrong.

  EDIT - FFMpeg Probe outputs for both videos...

  Video that works - https://justpaste.it/484ec .
  Video that fails - https://justpaste.it/55in0 .

• Revision 36c39d67b1 : Add shell scripts for verifying basic vpx{dec,enc} features. Tests the basics (

  3 avril 2014, par Tom Finegan

  Changed Paths :
   Add /test/tools_common.sh

  
   Add /test/vpxdec.sh

  
   Add /test/vpxenc.sh

  
  
  Add shell scripts for verifying basic vpxdec,enc features.

  Tests the basics (first confirms feature is available in vpx_config.h) :
   VP8 decode (in IVF file).
   VP9 decode (in WebM file).
   VP8 encode (to IVF and WebM).
   VP9 encode (to IVF and WebM).
   VP9 lossless encode (to IVF, currently disabled due to failure).
   Pipe input (to vpxdec and vpxenc).

  Test data path and path to vpxdec,enc have been parameterized. In
  addition :
   Supports disabling tests (test names prefixed with DISABLED_ are not
  run by default).
   Supports filtering tests.

  vpxdec.sh : Tests vpxdec.
  vpxenc.sh : Tests vpxenc.
  tools_common.sh : Common test functions.

  Change-Id : I0612c88b8dd6049a05bbbc79a317a0cca61733a5

• Anomalie #3382 : Un rédacteur peut consulter un document d’un article en cours de rédaction dont i...

  3 mai 2015, par b b

  Je pense qu’il faudrait définir l’autorisation comme suit :

  - si le document n’est lié à aucun objet, il est modifiable par un rédacteur
  - si le document n’est lié qu’à un seul objet, et que cet objet n’est pas modifiable par le rédacteur, alors le document n’est pas modifiable
  - reste à voir ce que l’on fait quand le document est lié à plusieurs objets : refus de modification si au moins un des objets lié au document n’est pas modifiable par le rédacteur ?

  D’autres avis ?