
Recherche avancée
Médias (1)
-
La conservation du net art au musée. Les stratégies à l’œuvre
26 mai 2011
Mis à jour : Juillet 2013
Langue : français
Type : Texte
Autres articles (42)
-
Les tâches Cron régulières de la ferme
1er décembre 2010, parLa gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
Le super Cron (gestion_mutu_super_cron)
Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...) -
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs -
Emballe médias : à quoi cela sert ?
4 février 2011, parCe plugin vise à gérer des sites de mise en ligne de documents de tous types.
Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ;
Sur d’autres sites (6775)
-
FFMPEG stereo track stops capturing at random times during a capture session
26 mai 2022, par mrwassenI am currently working on building a workflow to capture and archive a large stash of family and friends PAL and NTSC VHS tapes. The hardware setup is as follows :


- 

- JVC HR-7860S VCR
- s-video / RCA audio >
- ADVC-3000 converter
- SDI / BNC cable >
- Blackmagic Decklink Mini Recorder 4K PCIe card
- installed in a fairly hi-spec windows machine : AMD Ryzen 9 5900X 3.7 Ghz base 12 core, GEFORCE RTX 3060 12 gB, 32 gB ram














The plan is to capture to lossless AVI, then drop into an NLE (Vegas Pro v.16) to do a minimal amount of cleanup / trimming, then render to a more compressed video format (TBD) for upload to AWS S3 accessible through a family website.


The issue I am having is that when I run the capture using ffmpeg/directshow e.g. for a perfectly fine 90 min. PAL tape, at some random point of time during the capture one of the 2 stereo channels just stops capturing. This has happened with all of the tapes I have tested so far, and it happens at different times during the same video. I have examined the frames surrounding points in time when this happens, and it doesn't correlate to any transitions or jitter, but often just randomly in the middle of a perfectly smooth scene. Once the one channel stops capturing it never starts back up again during that capture session.


The ADVC-3000 and the VCR are both showing both stereo channels playing normally throughout the capture. The windows machine running the capture hardly breaks a sweat at any time, and the transfer easily keeps up constantly showing a speed = 1x which I assume means nothing lagging. Also there are no video/audio sync issues at any point in time even towards the end of long tapes e.g. 90 mins.


I am fairly new at ffmpeg, so I have spent extensive amounts of time reading up on forum posts and experimenting and have ended up with the following syntax :


ffmpeg -y -f dshow -rtbufsize 2000M -i video="Blackmagic WDM Capture":audio="Blackmagic WDM Capture" -codec:v v210 -pix_fmt yuv422p -codec:a pcm_s16le -b:a 128k -t 02:00:00 -r 25 -threads 4 -maxrate 2500k -filter:a "volume=1.5" output_v210_audio.avi



The capture runs without a single dropped frame, the only error I am getting when launching (and perhaps this is a smoking gun ?) is :




"Non-monotonous DTS in output stream 0:1 ; previous : 0, current : -30 ;
changing to 1. This may result in incorrect timestamps in the output
file."




I have tried to troubleshoot this in the hopes that it is tied to my issue but so far without luck.


Hoping somebody can help correct or modify my command line or perhaps other ideas to help resolve the issue.


-
Small Time DevOps
1er janvier 2021, par Multimedia Mike — GeneralWhen you are a certain type of nerd who has been on the internet for long enough, you might run the risk of accumulating a lot of projects and websites. Website-wise, I have this multimedia.cx domain on which I host a bunch of ancient static multimedia documents as well as this PHP/MySQL-based blog. Further, there are 3 other PHP/MySQL-based blogs hosted on subdomains. Also, there is the wiki, another PHP/MySQL web app. A few other custom PHP- and Python-based apps are running around on the server as well.
While things largely run on auto-pilot, I need to concern myself every now and then with their ongoing upkeep.
If you ask N different people about the meaning of the term ‘DevOps’, you will surely get N different definitions. However, whenever I have to perform VM maintenance, I like to think I am at least dipping my toes into the DevOps domain. At the very least, the job seems to be concerned with making infrastructure setup and upgrades reliable and repeatable.
Even if it’s not fully automated, at the very least, I have generated a lot of lists for how to make things work (I’m a big fan of Trello’s Kanban boards for this), so it gets easier every time (ideally, anyway).
Infrastructure History
For a solid decade, from 2004 to 2014, everything was hosted on shared, cPanel-based web hosting. In mid-2014, I moved from the shared hosting over to my own VPSs, hosted on DigitalOcean. I must have used Ubuntu 14.04 at the time, as I look down down the list of Ubuntu LTS releases. It was with much trepidation that I undertook this task (knowing that anything that might go wrong with the stack, from the OS up to the apps, would all be firmly my fault), but it turned out not to be that bad. The earliest lesson you learn for such a small-time setup is to have a frontend VPS (web server) and a backend VPS (database server). That way, a surge in HTTP requests has no chance of crashing the database server due to depleted memory.
At the end of 2016, I decided to refresh the VMs. I brought them up to Ubuntu 16.04 at the time.
Earlier this year, I decided it would be a good idea to refresh the VMs again since it had been more than 3 years. The VMs were getting long in the tooth. Plus, I had seen an article speculating that Azure, another notable cloud hosting environment, might be getting full. It made me feel like I should grab some resources while I still could (resource-hoarding was in this year).
I decided to use 18.04 for these refreshed VMs, even though 20.04 was available. I think I was a little nervous about 20.04 because I heard weird things about something called snap packages being the new standard for distributing software for the platform and I wasn’t ready to take that plunge.
Which brings me to this month’s VM refresh in which I opted to take the 20.04 plunge.
Oh MediaWiki
I’ve been the maintainer and caretaker of the MultimediaWiki for 15 years now (wow ! Where does the time go ?). It doesn’t see a lot of updating these days, but I know it still serves as a resource for lots of obscure technical multimedia information. I still get requests for new accounts because someone has uncovered some niche technical data and wants to make sure it gets properly documented.
MediaWiki is quite an amazing bit of software and it undergoes constant development and improvement. According to the version history, I probably started the MultimediaWiki with the 1.5 series. As of this writing, 1.35 is the latest and therefore greatest lineage.
This pace of development can make it a bit of a chore to keep up to date. This was particularly true in the old days of the shared hosting when you didn’t have direct shell access and so it’s something you put off for a long time.
Honestly, to be fair, the upgrade process is pretty straightforward :
- Unpack a set of new files on top of the existing tree
- Run a PHP script to perform any database table upgrades
Pretty straightforward, assuming that there are no hiccups along the way, right ? And the vast majority of the time, that’s the case. Until it’s not. I had an upgrade go south about a year and a half ago (I wasn’t the only MW installation to have the problem at the time, I learned). While I do have proper backups, it still threw me for a loop and I worked for about an hour to restore the previous version of the site. That experience understandably left me a bit gun-shy about upgrading the wiki.
But upgrades must happen, especially when security notices come out. Eventually, I created a Trello template with a solid, 18-step checklist for upgrading MW as soon as a new version shows up. It’s still a chore, just not so nerve-wracking when the steps are all enumerated like that.
As I compose the post, I think I recall my impetus for wanting to refresh from the 16.04 VM. 16.04 used PHP 7.0. I wanted to upgrade to the latest MW, but if I tried to do so, it warned me that it needed PHP 7.4. So I initialized the new 18.04 VM as described above… only to realize that PHP 7.2 is the default on 18.04. You need to go all the way to 20.04 for 7.4 standard. I’m sure it’s possible to install later versions of PHP on 16.04 or 18.04, but I appreciate going with the defaults provided by the distro.
I figured I would just stay with MediaWiki 1.34 series and eschew 1.35 series (requiring PHP 7.4) for the time being… until I started getting emails that 1.34 would go end-of-life soon. Oh, and there are some critical security updates, but those are only for 1.35 (and also 1.31 series which is still stubbornly being maintained for some reason).
So here I am with a fresh Ubuntu 20.04 VM running PHP 7.4 and MediaWiki 1.35 series.
How Much Process ?
Anyone who decides to host on VPSs vs, say, shared hosting is (or ought to be) versed on the matter that all your data is your own problem and that glitches sometimes happen and that your VM might just suddenly disappear. (Indeed, I’ve read rants about VMs disappearing and taking entire un-backed-up websites with them, and also watched as the ranters get no sympathy– “yeah, it’s a VM ; the data is your responsibility”) So I like to make sure I have enough notes so that I could bring up a new VM quickly if I ever needed to.
But the process is a lot of manual steps. Sometimes I wonder if I need to use some automation software like Ansible in order to bring a new VM to life. Why do that if I only update the VM once every 1-3 years ? Well, perhaps I should update more frequently in order to ensure the process is solid ?
Seems like a lot of effort for a few websites which really don’t see much traffic in the grand scheme of things. But it still might be an interesting exercise and might be good preparation for some other websites I have in mind.
Besides, if I really wanted to go off the deep end, I would wrap everything up in containers and deploy using D-O’s managed Kubernetes solution.
The post Small Time DevOps first appeared on Breaking Eggs And Making Omelettes.
-
Unknown input format : 'rawvideo' when trying to save animation
8 juin 2022, par John KlintSo, I get a strange error trying to save animations created with matplotlib.FuncAnimation using FFMpegWriter.


/home/j/PycharmProjects/venvtest/venv/bin/python /home/j/PycharmProjects/venvtest/main.py
MovieWriter stderr:
Unknown input format: 'rawvideo'

Traceback (most recent call last):
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/animation.py", line 234, in saving
 yield self
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/animation.py", line 1093, in save
 writer.grab_frame(**savefig_kwargs)
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/animation.py", line 351, in grab_frame
 self.fig.savefig(self._proc.stdin, format=self.frame_format,
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/figure.py", line 3046, in savefig
 self.canvas.print_figure(fname, **kwargs)
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/backend_bases.py", line 2319, in print_figure
 result = print_method(
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/backend_bases.py", line 1648, in wrapper
 return func(*args, **kwargs)
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/_api/deprecation.py", line 415, in wrapper
 return func(*inner_args, **inner_kwargs)
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/backends/backend_agg.py", line 486, in print_raw
 fh.write(renderer.buffer_rgba())
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "/home/j/PycharmProjects/venvtest/main.py", line 24, in <module>
 anim.save('basic_animation.mp4', writer=FFwriter)
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/animation.py", line 1093, in save
 writer.grab_frame(**savefig_kwargs)
 File "/usr/lib/python3.9/contextlib.py", line 137, in __exit__
 self.gen.throw(typ, value, traceback)
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/animation.py", line 236, in saving
 self.finish()
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/animation.py", line 342, in finish
 self._cleanup() # Inline _cleanup() once cleanup() is removed.
 File "/home/j/PycharmProjects/venvtest/venv/lib/python3.9/site-packages/matplotlib/animation.py", line 373, in _cleanup
 raise subprocess.CalledProcessError(
subprocess.CalledProcessError: Command '['/usr/bin/ffmpeg', '-f', 'rawvideo', '-vcodec', 'rawvideo', '-s', '640x480', '-pix_fmt', 'rgba', '-r', '5', '-loglevel', 'error', '-i', 'pipe:', '-vcodec', 'h264', '-pix_fmt', 'yuv420p', '-y', 'basic_animation.mp4']' returned non-zero exit status 1.

Process finished with exit code 1
</module>


I am confident it has nothing to do with the animation data, the error occurs even when I create a simple test animation :


import numpy as np
from matplotlib import pyplot as plt
from matplotlib import animation
# plt.rcParams['animation.ffmpeg_path'] = '/usr/bin/ffmpeg'

fig = plt.figure()
ax = plt.axes(xlim=(0, 2), ylim=(-2, 2))
line, = ax.plot([], [], lw=2)


def init():
 line.set_data([], [])
 return line,


def animate(i):
 x = np.linspace(0, 2, 1000)
 y = np.sin(2 * np.pi * (x - 0.01 * i))
 line.set_data(x, y)
 return line,


anim = animation.FuncAnimation(fig, animate, init_func=init,
 frames=200, interval=20, blit=True)

FFwriter = animation.FFMpegWriter()
anim.save('basic_animation.mp4', writer=FFwriter)



I am currently using PyCharm in LinuxMint and I have a fairly new version of FFMpeg (4.2.4) installed. Given that FFMpeg complains about 'rawvideo' which as far as I understand it is just a bunch of images in series, it seems unlikely this has anything to do with codecs. If I run ffmpeg -formats, sure enough rawvideo is in the list.


I have tried manually setting plt.rcParams, like in the commented line in the code above, with no success. I have also tried setting up both anaconda and venv environments, but I get the same error.
Annoyingly, I did not have this problem a few months ago when I was using Ubuntu. I have also verified that it works on my friends Ubuntu desktop, using the same simple venv as I set up for myself.


Any ideas ?


EDIT : I use the fish shell, if that is relevant...


Well this is peculiar. If I start a terminal from within PyCharm and check supported formats, I get the following :


(venv) ffmpeg -formats
ffmpeg version 4.3.4 Copyright (c) 2000-2021 the FFmpeg developers
 built with gcc 11.3.0 (GCC)
 configuration: --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu --disable-debug --disable-doc --disable-static --enable-optimizations --enable-shared --disable-everything --enable-ffplay --enable-ffprobe --enable-gnutls --enable-libaom --enable-libdav1d --enable-libfdk-aac --enable-libmp3lame --enable-libfontconfig --enable-libfreetype --enable-libopus --enable-libpulse --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libwebp --enable-openal --enable-opengl --enable-sdl2 --enable-vulkan --enable-zlib --enable-libv4l2 --enable-libxcb --enable-vdpau --enable-vaapi --enable-encoder='ac3,alac,flac,libfdk_aac,g723_1,mp2,libmp3lame,libopus,libspeex,pcm_alaw,pcm_mulaw,pcm_f32le,pcm_s16be,pcm_s24be,pcm_s16le,pcm_s24le,pcm_s32le,pcm_u8,tta,libvorbis,wavpack,' --enable-encoder='ass,ffv1,libaom_av1,libvpx_vp8,libvpx_vp9,mjpeg_vaapi,rawvideo,theora,vp8_vaapi,libopenh264' --enable-decoder='adpcm_g722,alac,flac,g723_1,g729,libfdk_aac,libopus,libspeex,mp2,mp3,m4a,pcm_alaw,pcm_mulaw,pcm_f16le,pcm_f24le,pcm_f32be,pcm_f32le,pcm_f64be,pcm_f64le,pcm_s16be,pcm_s16be_planar,pcm_s24be,pcm_s16le,pcm_s16le_planar,pcm_s24le,pcm_s24le_planar,pcm_s32le,pcm_s32le_planar,pcm_s64be,pcm_s64le,pcm_s8,pcm_s8_planar,pcm_u8,pcm_u24be,pcm_u24le,pcm_u32be,pcm_u32le,tta,vorbis,wavpack,' --enable-decoder='ass,ffv1,mjpeg,mjpegb,libaom_av1,libdav1d,libvpx_vp8,libvpx_vp9,rawvideo,theora,vp8,vp9,libopenh264' --enable-encoder='bmp,gif,jpegls,png,tiff,webp,' --enable-decoder='bmp,gif,jpegls,png,tiff,webp,' --enable-hwaccel='vp8_vaapi,mjpeg_vaapi,' --enable-parser='aac,ac3,flac,mjpeg,mpegaudio,mpeg4video,opus,vp3,vp8,vp9,vorbis,' --enable-muxer='ac3,ass,flac,g722,gif,matroska,mp3,mpegvideo,rtp,ogg,opus,pcm_s16be,pcm_s16le,wav,webm,' --enable-demuxer='aac,ac3,ass,flac,g722,gif,image_jpeg_pipe,image_png_pipe,image_webp_pipe,matroska,mjpeg,mov,mp3,mpegvideo,ogg,pcm_mulaw,pcm_alaw,pcm_s16be,pcm_s16le,rtp,wav,' --enable-filter='crop,scale,overlay,amix,amerge,aresample,format,aformat,fps,transpose,pad,' --enable-protocol='crypto,file,pipe,rtp,srtp,rtsp,tcp,udp,unix,' --arch=x86_64 --enable-libopenh264
 libavutil 56. 51.100 / 56. 51.100
 libavcodec 58. 91.100 / 58. 91.100
 libavformat 58. 45.100 / 58. 45.100
 libavdevice 58. 10.100 / 58. 10.100
 libavfilter 7. 85.100 / 7. 85.100
 libswscale 5. 7.100 / 5. 7.100
 libswresample 3. 7.100 / 3. 7.100
File formats:
 D. = Demuxing supported
 .E = Muxing supported
 --
 D aac raw ADTS AAC (Advanced Audio Coding)
 DE ac3 raw AC-3
 D alaw PCM A-law
 D asf ASF (Advanced / Active Streaming Format)
 DE ass SSA (SubStation Alpha) subtitle
 DE flac raw FLAC
 DE g722 raw G.722
 DE gif CompuServe Graphics Interchange Format (GIF)
 D jpeg_pipe piped jpeg sequence
 E matroska Matroska
 D matroska,webm Matroska / WebM
 D mjpeg raw MJPEG video
 D mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV
 DE mp3 MP3 (MPEG audio layer 3)
 D mpegts MPEG-TS (MPEG-2 Transport Stream)
 D mpegvideo raw MPEG video
 D mulaw PCM mu-law
 DE ogg Ogg
 E opus Ogg Opus
 D png_pipe piped png sequence
 D rm RealMedia
 DE rtp RTP output
 DE s16be PCM signed 16-bit big-endian
 DE s16le PCM signed 16-bit little-endian
 D sdp SDP
 DE wav WAV / WAVE (Waveform Audio)
 E webm WebM
 D webp_pipe piped webp sequence




As is evident, there is no support for 'rawvideo' in the list above ! Very strange indeed, I do not know which ffmpeg this list belongs to, perhaps it is a version integrated into matplotlib's animation class ?


Anyway, if I uncomment the line setting the ffmpeg_path I am back at the old error. I did get it to work however, by changing the path from '/usr/bin/ffmpeg' to '/home/j/.conda/envs/venvtest/bin/ffmpeg'. Then I get the file to run, create the animation and save it. This works for my real files as well, which do not even run that particular conda-environment. They do not recognize or find the ffmpeg I have in /usr/bin though. I have no clue why but at least I have a workaround now.


Final edit :
It is solved. It was flatpak's fault. Lesson is, don't use flatpak (or snap for that matter) to install Pycharm.