Recherche avancée

Sur d’autres sites (7577)

• Revision c667593e1e : Merge changes from topic 'fix-vp9-bitstream-test' * changes : vp9_encoder_parm

  16 septembre 2015, par James Zern

  Changed Paths :
   Modify /vp10/encoder/encoder.c

  
   Modify /vp10/vp10_dx_iface.c

  
   Modify /vp9/encoder/vp9_encoder.c

  
  
  Merge changes from topic ’fix-vp9-bitstream-test’

  * changes :
  vp9_encoder_parms_get_to_decoder : cosmetics
  vp9...parms_get_to_decoder : remove unneeded func
  vp9...parms_get_to_decoder : fix EXPECT param order
  vp9_encoder_parms_get_to_decoder : delete dead code
  fix BitstreamParms test
  vp9_encoder_parms_get_to_decoder : remove vp10
  yuvconfig2image() : add explicit cast to avoid conv warning
  vp9/10 decoder_init : add missing alloc cast
  vp9/10 : set color_space on preview frame
  vp10 : add extern "C" to headers
  vp9 : add extern "C" to headers

• tcp : Explicitly convert a pointer to a boolean integer

  9 septembre 2013, par Martin Storsjö

  tcp : Explicitly convert a pointer to a boolean integer
  This fixes warnings about making integers from pointers without
  
  a cast, and avoids the theoretical case where the lower 32 bits of
  
  the pointer would all be zero where the implicit cast wouldn’t give
  
  the right result.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/tcp.c

• Different filesizes for images generated using octave and python

  22 février 2017, par Lakshay Garg

  I am using python (scikit-image) and octave to generate 200 images as follows

  Python3

  import numpy as np
  
  from skimage.io import imsave
  
  
  
  images = [255*np.ones((100,100), dtype=np.uint8),  # white
  
               np.zeros((100,100), dtype=np.uint8)]  # black
  
  
  
  for i in range(200): # save alternating black and white images
  
      imsave('%04d.png'%(i+1), images[i%2])

  Octave

  pkg load image;
  
  
  
  im1 = 255*ones(100,100); # white
  
  im2 = zeros(100,100);    # black
  
  for i=1:200
  
      name = sprintf('%04d.png', i);
  
      if mod(i,2) == 0
  
          imwrite(im1, name);
  
      else
  
          imwrite(im2, name);
  
      end
  
  end

  Next, I use ffmpeg to generate two videos (alternating white and black frames) from these two sets of images using the following command

  ffmpeg -r 10 -loglevel quiet \
  
         -i ./%04d.png -c:v libx264 \
  
         -preset ultrafast -crf 0 ./out.mkv

  1. Sizes of image files generated by both these codes are different.

     • Octave white : 192 bytes, black : 98 bytes
     • Python white : 120 bytes, black : 90 bytes

  2. Sizes of video files generated from these octave and python images are significantly different from each other.

     • Octave filesize : 60 kilobytes
     • Python filesize : 116 kilobytes

  Why do we have this apparently very strange behavior ?

  EDIT

  Since it was suggested that the behavior might be dues to octave and python using different bit-depths to store the images, I changes the octave code to use 8 bit numbers

  im1 = uint8(255*ones(100,100)); # white
  
  im2 = uint8(zeros(100,100));    # black

  and now the image file sizes are nearly the same

  • Octave white : 118 bytes, black : 90 bytes
  • Python white : 120 bytes, black : 90 bytes

  but the problem is still the same for video files, octave : 60K, python : 116K