Recherche avancée

Sur d’autres sites (6427)

• Animated line chart with pandas, matplotlib and ffmpeg

  10 avril 2020, par Mark K

  In producing an animated line chart, I have below data and codes.

  



  But when the chart produced, it shows no line. What did I do wrong ?

  



  Thank you.

  



  import numpy as np
import pandas as pd
import seaborn as sns
import matplotlib
import matplotlib.pyplot as plt
import matplotlib.animation as animation

title = 'Heroin Overdoses'

data = {'Year' : ["1999","2000","2001","2002","2003","2004","2005","2006","2007","2008","2009","2010","2011","2012","2013","2014","2015","2016"], 
'Heroin Overdoses' : [280,443,413,486,475,148,197,170,448,103,137,160,483,356,352,300,466,278]}
overdose = pd.DataFrame(data)

Writer = animation.writers['ffmpeg']
writer = Writer(fps=20, metadata=dict(artist='Me'), bitrate=1800)

fig = plt.figure(figsize=(10,6))
plt.xlim(1999, 2016)
plt.ylim(np.min(overdose)[0], np.max(overdose)[0])
plt.xlabel('Year',fontsize=20)
plt.ylabel(title,fontsize=20)
plt.title('Heroin Overdoses per Year',fontsize=20)

def animate(i):
    data = overdose.iloc[:int(i+1)] #select data range
    p = sns.lineplot(x=data.index, y=data[title], data=data, color="r")
    p.tick_params(labelsize=17)
    plt.setp(p.lines,linewidth=7)

ani = matplotlib.animation.FuncAnimation(fig, animate, frames=17, repeat=True)

ani.save('C:\\folder\\line chart.mp4', writer=writer)


  


• Correct way for working with raw data when encoding using FFmpeg

  25 avril 2020, par midnightcoffee

  I am working on the android library for encoding/decoding raw data through ffmpeg. Every example I found uses files, it either reads or writes to a file. However, I am using raw byte array representing RGBA  image for encoder input and byte array for encoder output. Lets focus on encoding part for this question.

  



  My function looks like this : 

  



  int encodeRGBA(uint8_t *image, int imageSize, int presentationTimestamp,
 uint8_t *result, int resultSize)


  



  Where image is byte array containing raw rgba image data, imageSize is length of that array, presentationTimestamp is just counter used by AVFrame for setting pts, result is preallocated byte array with some defined length (currently with size matching width x height) and resultSize is byte array length (width x height). Returned int value represents actually used length of preallocated array. I am aware that this is not the best approach for sending data back to java and this is also part of the question. Is there a better way for returning result ?

  



  Example found here for encoding, directly writes byte data to the frame->data[0] (different approach for different formats, RGBA or YUV). But google search for "ffmpeg read from memory" results in examples like this, this or this. All of them suggesting using AVIOContext.

  



  I am confused how to use AVFormatContext with AVCodecContext for encoding ?

  



  Currently I have encoder working using first approach and I am successfully returning results as described (with preallocated byte array). I would like to know if that is wrong approach ? Should I be using AVIOContext for handling byte arrays ?

  


• Anomalie #4430 (En cours) : image_reduire gère mal les arrondis

  4 février 2020, par jluc -

  image_reduire200,200 produit parfois des images de 201px de haut ce qui semble bien peu de différence mais fait riper certaines mises en page.

  Ça semble venir de 2 phénomènes :
  - les calculs aboutissent à des images légèrement différentes de 200px
  - les arrondis pour les dimensions width et height de la balise IMG forcent le passage à 201px pour la hauteur

  Sur le document badto200.jpg uploadé, voici 1 code qui manifeste le pb :
  -

  [(#FICHIER|image_proportions1,1,focus|image_reduire200,200)]

  In situ, c’est dans un portfolio avec bootstrap 3 :
  

  ...

  
  et ça produit des résultats avec de gros blancs comme sur l’image screenshot.jpg

  Je résoud le problème en doublant l’appel à |image_reduire(200,200). J’espère que le filtre est optimisé quand ya rien à faire... Mais il devrait être possible de mieux viser les (200,200).