
Recherche avancée
Autres articles (25)
-
Encoding and processing into web-friendly formats
13 avril 2011, parMediaSPIP automatically converts uploaded files to internet-compatible formats.
Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
All uploaded files are stored online in their original format, so you can (...) -
Support de tous types de médias
10 avril 2011Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)
-
List of compatible distributions
26 avril 2011, parThe table below is the list of Linux distributions compatible with the automated installation script of MediaSPIP. Distribution nameVersion nameVersion number Debian Squeeze 6.x.x Debian Weezy 7.x.x Debian Jessie 8.x.x Ubuntu The Precise Pangolin 12.04 LTS Ubuntu The Trusty Tahr 14.04
If you want to help us improve this list, you can provide us access to a machine whose distribution is not mentioned above or send the necessary fixes to add (...)
Sur d’autres sites (6475)
-
Revision 3c34619125 : Fix initialization order for the encoder This commit makes the coefficient tree
4 décembre 2013, par Jingning HanChanged Paths :
Modify /vp9/encoder/vp9_onyx_if.c
Fix initialization order for the encoderThis commit makes the coefficient tree initialized prior to token
initialization, where the coefficient costs are filled out according
to the probabilities associated with coefficient value categories.Change-Id : If4e89c3923058376f8382c683fe4a225a4a38af3
-
build : fix make checkheaders in out-of-tree builds
23 janvier 2016, par Andreas Cadhalpun -
FFMpegWriter not using the bitrate specified ? Animation is very blurry
18 mai 2022, par ceboI am using
matplotlib
'sFunAnimation
as well asFFMpegWriter
to try to write a simulation animation to a file. I'd like to save a high quality version of it, but when I increase thebitrate
value of the writer, the actual bitrate of the.mp4
it creates seems to increase in discrete steps up to a fairly low value after which it doesn't increase any more whatsoever.

My code is roughly :


dpi = 96
fig = plt.figure(figsize=(width/dpi, height/dpi), dpi=dpi)
anim = FuncAnimation(fig, myAnimation, frames=100, interval=1, blit=True)
writer = animation.FFMpegWriter(fps=10, bitrate=<some number="number">)
anim.save('MyAnimation.mp4', writer=writer)
</some>


The animation is only 200x200px so I feel like it shouldn't be a problem to have a high quality video, but I can't seem to get a high enough bitrate. For the following bitrates specified in my code, the actual bitrate shown in the files properties are :


BR In Code => Actual BR (kbps)
-1 / None => 13
100 => 58
1000 => 76
10000 => 76



The bitrate doesn't seem to track very well at all, and won't go above
76kbps
at all. The video is still badly blurry at this bitrate.

What do I need to do to increase the bitrate or else the quality of the video file ?


Alternatively, is there a better video format/writer to use for this purpose ? Specifically one that is broadly supported so I could embed it in a website or upload it to YouTube or something like that.


Edit :


To be more specific about the issue, neighboring pixels are being blended together, resulting in a blurry look. The following imgur album shows several examples with different settings :




These include the view in the figure window from
plt.show()
, default bitrate, a "high" bitrate, and something else I just tried which was to increase the dpi. While the results are much nicer it also nearly doubled the execution time so I'd like to avoid it.

It seems silly to have to upscale what is effectively "pixel art" in order for it to look good, but I guess this is an artifact of the signal processing approach mpeg uses, which is why I suspect a different file format might be the best solution for small framed animations like this. If I wanted to do a 1920*1080 animation the blurring would probably be less of an issue.