
Recherche avancée
Médias (1)
-
The Great Big Beautiful Tomorrow
28 octobre 2011, par
Mis à jour : Octobre 2011
Langue : English
Type : Texte
Autres articles (59)
-
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
MediaSPIP v0.2
21 juin 2013, parMediaSPIP 0.2 est la première version de MediaSPIP stable.
Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...) -
Creating farms of unique websites
13 avril 2011, parMediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)
Sur d’autres sites (8584)
-
How do I make ffmpeg not open a window when used in Python (Discord Bot Youtube Audio Player Pytube)
20 juin 2019, par BrandalfI am using pytube to create a Discord bot that gets audio from a YouTube video and plays it in the voice channel using the code below. The code works perfectly fine and does what I want which is playing audio from YouTube with a link. The issue is that it uses ffmpeg and when it does, it opens the ffmpeg.exe window. Having a window constantly pop up on my screen is kind of annoying but what’s worse is that if I am playing a game in full screen, when ffmpeg is run, it will tab out of my game. So I’m wondering if there is a way to prevent ffmpeg from opening the window or if there is an alternative to playing youtube audio in Discord with a bot that doesn’t use ffmpeg.
user=ctx.message.author
voice_channel=user.voice.voice_channel
vc = await client.join_voice_channel(voice_channel)
player = await vc.create_ytdl_player(videoLink)
video = pafy.new(videoLink) #runs ffmpeg
player.start() -
To get OpenCV VideoWriter work across platforms consistently for MP4 container with H264 encoding
28 mars 2019, par MohI am trying to get OpenCV VideoWriter work across platform consistently for MP4 container with H246 encoding.
Target platforms in order of importance - Ubuntu, Raspbian, OSX
Basically, my shortcoming at this point is not understanding the relationship of FourCC code (as a parameter to OpenCV VideoWriter) to the FFMPEG backend and its requirements. I am interested to understand the game in play rather than discussing a piece of code.
What I want to know is when I specify ’X264’ as FourCC code trying to write an x.MP4 file (FFMPEG backend) and the request is marshalled to FFMPEG what requirements/dependencies need to be satisfied by the OS for it to success.
So far I have got my python stack writing MP4 video files across Raspbian/Ubuntu/OSX, with a hack.
On my Raspbian stretch installation, I use 0x00000021 as the fourCC code.
On Ubuntu (VM on OSX) and on OSX, AVC1 works.Days of Googling only delivered those hacks, not a good understanding of the problem.
The x264 as FourCC code leads to one of - failure, non-portable video file + annoying FFMPEG warning.
I am trying to get to the bottom of it.
The code,
#self.__fourCC = cv2.VideoWriter_fourcc('x', '2', '6', '4')
self.__fourCC = cv2.VideoWriter_fourcc('a', 'v', 'c', '1')
if PlatformUtils.isRunningOnRaspberryPi():
self.__fourCC = 0x00000021I have control over the version both OpenCV and FFMPEG (if required GStreamer too). I can and have built them for Ubuntu/Raspbian.
-
To get OpenCV VideoWriter work across platforms consistently for MP4 container with H264 encoding
28 mars 2019, par MohI am trying to get OpenCV VideoWriter work across platform consistently for MP4 container with H246 encoding.
Target platforms in order of importance - Ubuntu, Raspbian, OSX
Basically, my shortcoming at this point is not understanding the relationship of FourCC code (as a parameter to OpenCV VideoWriter) to the FFMPEG backend and its requirements. I am interested to understand the game in play rather than discussing a piece of code.
What I want to know is when I specify ’X264’ as FourCC code trying to write an x.MP4 file (FFMPEG backend) and the request is marshalled to FFMPEG what requirements/dependencies need to be satisfied by the OS for it to success.
So far I have got my python stack writing MP4 video files across Raspbian/Ubuntu/OSX, with a hack.
On my Raspbian stretch installation, I use 0x00000021 as the fourCC code.
On Ubuntu (VM on OSX) and on OSX, AVC1 works.Days of Googling only delivered those hacks, not a good understanding of the problem.
The x264 as FourCC code leads to one of - failure, non-portable video file + annoying FFMPEG warning.
I am trying to get to the bottom of it.
The code,
#self.__fourCC = cv2.VideoWriter_fourcc('x', '2', '6', '4')
self.__fourCC = cv2.VideoWriter_fourcc('a', 'v', 'c', '1')
if PlatformUtils.isRunningOnRaspberryPi():
self.__fourCC = 0x00000021I have control over the version both OpenCV and FFMPEG (if required GStreamer too). I can and have built them for Ubuntu/Raspbian.