Recherche avancée

Sur d’autres sites (10308)

• 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

• dashenc : allow assigning all streams of a media type to an AdaptationSet

  29 janvier 2017, par Peter Große

  dashenc : allow assigning all streams of a media type to an AdaptationSet
  Using the characters "v" or "a" instead of stream index numbers for assigning
  
  streams in the adaption_set option, all streams matching that given type will
  
  be added to the AdaptationSet.
  Signed-off-by : Peter Große <pegro@friiks.de>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavformat/dashenc.c

• Could not read frame error when trying to decompress mp4 file with ffmpeg and Python's threading module

  23 janvier 2017, par mdornfe1

  I’m training constitutional neural networks with video data. So far the bottle neck of my application is decompressing the mp4 files before passing the images to the CNN for training. I had the idea to try to have multiple cpu threads decompress the images concurrently and having one thread pass images to the CNN for training. I made a class VideoStream which makes connection to the mp4 file using the ImageIO module which is built on top of ffmpeg. The structure of my program is a follows :

  1) Generate random ints which represent the frame numbers of the mp4 file that will be used in training. Store these ints in list frame_idxs.

  2) Pass this list of ints and an empty list called frame_queue to the worker function decompress_video_data.

  3) Each worker function makes a connection to the mp4 file using VideoStream.

  4) Each worker function then pops of elements of frame_idxs, decompresses that frame, and then stores that frame as numpy array in list frame_queue.

  Here is the code

  import numpy as np
  
  import os, threading, multiprocessing
  
  
  
  
  
  def decompress_video_data(frame_queue, frame_idxs, full_path):
  
      vs = VideoStream(full_path)
  
      while len(frame_idxs) >1 0:
  
          i = frame_idxs.pop()
  
          frame = vs[i]
  
          frame_queue.append(frame)
  
  
  
  video_folder = '/mnt/data_drive/frame_viewer_client'
  
  video_files = os.listdir(video_folder)
  
  video_file = video_files[0]
  
  full_path = os.path.join(video_folder, video_file)
  
  vs = VideoStream(full_path)
  
  
  
  num_samples = 1000
  
  batch_size = 1
  
  frame_queue = []
  
  decompress_threads = []
  
  frame_idxs = list(np.random.randint(0, len(vs), 
  
      size = batch_size * num_samples))
  
  num_cores = multiprocessing.cpu_count()
  
  
  
  for n in range(num_cores - 1):
  
      decompress_thread = threading.Thread(target=decompress_video_data, 
  
          args=(frame_queue, frame_idxs, full_path))
  
      decompress_threads.append(decompress_thread)
  
      decompress_thread.start()

  The program will sucessfuly decompress approximately 200 frames, and then ImageIO will throw an RuntimeError : Could not read frame. The full error is here. Does anyone know why this is happening ? Is it possible to do what I’m trying to do ? Does ffmpeg just not work with multi threading ?