
Recherche avancée
Médias (1)
-
Spitfire Parade - Crisis
15 mai 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
Autres articles (3)
-
Les images
15 mai 2013 -
Le plugin : Gestion de la mutualisation
2 mars 2010, parLe plugin de Gestion de mutualisation permet de gérer les différents canaux de mediaspip depuis un site maître. Il a pour but de fournir une solution pure SPIP afin de remplacer cette ancienne solution.
Installation basique
On installe les fichiers de SPIP sur le serveur.
On ajoute ensuite le plugin "mutualisation" à la racine du site comme décrit ici.
On customise le fichier mes_options.php central comme on le souhaite. Voilà pour l’exemple celui de la plateforme mediaspip.net :
< ?php (...) -
Pas question de marché, de cloud etc...
10 avril 2011Le vocabulaire utilisé sur ce site essaie d’éviter toute référence à la mode qui fleurit allègrement
sur le web 2.0 et dans les entreprises qui en vivent.
Vous êtes donc invité à bannir l’utilisation des termes "Brand", "Cloud", "Marché" etc...
Notre motivation est avant tout de créer un outil simple, accessible à pour tout le monde, favorisant
le partage de créations sur Internet et permettant aux auteurs de garder une autonomie optimale.
Aucun "contrat Gold ou Premium" n’est donc prévu, aucun (...)
Sur d’autres sites (1816)
-
ffmpeg, video-clips do not always end at the specified '-to' value
21 mars 2023, par query-01Within the batch file below, I randomly experience a video-clip that will not truncate/end at the value entered for
-to
. That said, if I have four files joined, then output tooutput.mp4
, at least one file will not end at the specified-to
value, yet the other adjoining clips will have complied with their specified-to
value.

@echo off
Setlocal EnableDelayedExpansion
Rem "C:\Program Files\Bulk Rename Utility\Bulk Rename Utility.exe" %CD%
for /F "delims=" %%i in ('dir /B /O *.mp4') do (
 set f=%%i
 "C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" "!f!"
 set /p ss="Enter hh:mm:ss: "
 set /p t="Enter Duration: "
 ffmpeg -i "!f!" -ss !ss! -to !t! -c:v copy -c:a aac _"!f!"
)

for /F "delims=" %%i in ('dir /B /O _*.mp4') do @echo file '%%i' >> clips.txt
set /p fn="Enter A Filename:"
ffmpeg -safe 0 -f concat -i clips.txt -c:v copy -c:a aac !fn!.mp4



All of the video-clips are processed by the original system and remain un_touched before they are handled by this script.


What am I doing incorrectly, and/or, what should I be looking for within the affected video-clip, which would cause this behavior ?


I am using ffmpeg version 2021-11-10-git-44c65c6cc0-full_build-www.gyan.dev on Windows 10 Home, Version : 22H2


Respectfully.


-
discord.py music bot slowing down for longer audio queries
1er janvier 2023, par BoblugeSo I'm trying to make a music bot with discord.py. Shown below is a minimum working example of the bot with the problematic functions :


import os

import discord
from discord.ext import commands
from discord import player as p

import yt_dlp as youtube_dl

intents = discord.Intents.default()
intents.members = True

bot = commands.Bot(command_prefix=';')

class Music(commands.Cog):
 def __init__(self, bot):
 self.bot = bot
 self.yt-dlp_opts = {
 'format': 'bestaudio/best',
 'outtmpl': '%(extractor)s-%(id)s-%(title)s.%(ext)s',
 'restrictfilenames': True,
 'noplaylist': True,
 'playlistend': 1,
 'nocheckcertificate': True,
 'ignoreerrors': False,
 'logtostderr': False,
 'quiet': True,
 'no_warnings': True,
 'default_search': 'auto',
 'source_address': '0.0.0.0', # bind to ipv4 since ipv6 addresses cause issues sometimes
 }
 self.ffmpeg_opts = {
 'options': '-vn',
 # Source: https://stackoverflow.com/questions/66070749/
 "before_options": "-reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 5",
 }
 self.cur_stream = None
 self.cur_link = None

 @commands.command(aliases=["p"])
 async def play(self, ctx, url):
 yt-dlp = youtube_dl.YoutubeDL(self.ytdl_opts)
 data = yt-dlp.extract_info(url, download=False)
 filename = data['url'] # So far only works with links
 print(filename)
 audio = p.FFmpegPCMAudio(filename, **self.ffmpeg_opts)
 self.cur_stream = audio
 self.cur_link = filename

 # You must be connected to a voice channel first
 await ctx.author.voice.channel.connect()
 ctx.voice_client.play(audio)
 await ctx.send(f"now playing")

 @commands.command(aliases=["ff"])
 async def seek(self, ctx):
 """
 Fast forwards 10 seconds
 """
 ctx.voice_client.pause()
 for _ in range(500):
 self.cur_stream.read() # 500*20ms of audio = 10000ms = 10s
 ctx.voice_client.resume()

 await ctx.send(f"fast forwarded 10 seconds")

 @commands.command(aliases=["j"])
 async def jump(self, ctx, time):
 """
 Jumps to a time in the song, input in the format of HH:MM:SS
 """
 ctx.voice_client.stop()
 temp_ffempg = {
 'options': '-vn',
 # Keyframe skipping when passed as an input option (fast)
 "before_options": f"-ss {time} -reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 5",
 }
 new_audio = p.FFmpegPCMAudio(self.cur_link, **temp_ffempg)
 self.cur_stream = new_audio
 ctx.voice_client.play(new_audio)
 await ctx.send(f"skipped to {time}")


bot.add_cog(Music(bot))
bot.run(os.environ["BOT_TOKEN"])



My
requirements.txt
file :

discord.py[voice]==1.7.3
yt-dlp==2021.9.2



To play a song in Discord the following format is used :


;p 



Where
is any link that yt-dlp supports. Under normal circumstances, the
;p
command is used with songs that are relatively short, to whichseek()
andjump()
work extremely quickly to do what they are supposed to do. For example if I execute these sequence of commands in Discord :

;p https://www.youtube.com/watch?v=n8X9_MgEdCg <- 4 min song



And when the bot starts playing, spam the following :


;ff
;ff
;ff
;ff
;ff



The bot is able to almost instantly seek five 10-second increments of the song. Additionally, I can jump to the three minute mark very quickly with :


;j 00:03:00



From some experimentation, the
seek()
andjump()
functions seem to work quickly for songs that are under 10 minutes. If I try the exact same sequence of commands but with a 15 minute song likehttps://www.youtube.com/watch?v=Ks9Ck5LfGWE
or longerhttps://www.youtube.com/watch?v=VThrx5MRJXA
(10 hours classical music), there is an evident slowdown when running the;ff
command. However, when I include a few seconds of delay between firings of the;ff
command, the seeking is just as fast as previously mentioned. I'm not exactly sure what is going on with yt-dlp/FFmpeg behind the scenes when streaming, but I speculate that there is some sort of internal buffer, and songs that pass a certain length threshold are processed differently.

For longer songs, the
seek()
command takes longer to get to the desired position, which makes sense since this site specifies that-ss
used as an input option loops through keyframes (as there must be more keyframes in longer songs). However, if the following commands are run in Discord :

;p https://www.youtube.com/watch?v=VThrx5MRJXA <- 10 hour classical music
;j 09:00:00 <- jump to 9 hour mark
;j 00:03:00 <- jump to 3 minute mark



The first seek command takes around 5 to 10 seconds to perform a successful seek, which isn't bad, but it could be better. The second seek command takes around the same time as the first command, which doesn't make sense to me, because I thought less keyframes were skipped in order to reach the 3 minute mark.


So I'm wondering what's going on, and how to potentially solve the following :


- 

- What is actually going on with the
seek()
command ? My implementation ofseek()
uses discord.py'sdiscord.player.FFmpegPCMAudio.read()
method, which apparently runs slower if the song's length is longer ? Why ? - Why does input seeking for long YouTube videos take almost the same time no matter where I seek to ?
- How the yt-dlp and FFmpeg commands work behind the scenes to stream a video from YouTube (or any other website that YTDL supports). Does yt-dlp and FFmpeg behave differently for audio streams above a certain length threshold ?
- Potential ways to speed up
seek()
andjump()
for long songs. I recall some well-known discord music bots were able to do this very quickly.










- What is actually going on with the
-
ffmpeg overlay png on video has color issue
9 janvier 2023, par RichardIm trying a simple overlay command to put a logo on a black video, but find the color a little different in output, the original RGB value of green part of the logo is (0,220,90), but changed to (0,191,88) in output. Looks like the color gets mixed with the black background, any ideas ?


original logo rgb :




rgb after logo overlayed on video :




the command to overlay :


ffmpeg -i video.mp4 -i logo.png -filter_complex "[1:v]format=rgba[s],[0:v][s]overlay=240:1275:format=auto" output.mp4





▶ ffmpeg -i logo.png 
ffmpeg version 4.4-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2021 the FFmpeg developers
 built with gcc 8 (Debian 8.3.0-6)
 configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg
 libavutil 56. 70.100 / 56. 70.100
 libavcodec 58.134.100 / 58.134.100
 libavformat 58. 76.100 / 58. 76.100
 libavdevice 58. 13.100 / 58. 13.100
 libavfilter 7.110.100 / 7.110.100
 libswscale 5. 9.100 / 5. 9.100
 libswresample 3. 9.100 / 3. 9.100
 libpostproc 55. 9.100 / 55. 9.100 
Input #0, png_pipe, from 'logo.png':
 Duration: N/A, bitrate: N/A
 Stream #0:0: Video: png, rgba(pc), 601x81 [SAR 2834:2834 DAR 601:81], 25 fps, 25 tbr, 25 tbn, 25 tbc

▶ ffmpeg -i video.mp4 
ffmpeg version 4.4-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2021 the FFmpeg developers
 built with gcc 8 (Debian 8.3.0-6)
 configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg
 libavutil 56. 70.100 / 56. 70.100
 libavcodec 58.134.100 / 58.134.100
 libavformat 58. 76.100 / 58. 76.100
 libavdevice 58. 13.100 / 58. 13.100
 libavfilter 7.110.100 / 7.110.100
 libswscale 5. 9.100 / 5. 9.100
 libswresample 3. 9.100 / 3. 9.100
 libpostproc 55. 9.100 / 55. 9.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'video.mp4':
 Metadata:
 major_brand : isom
 minor_version : 512
 compatible_brands: isomiso2avc1mp41
 encoder : Lavf58.76.100
 Duration: 00:00:02.00, start: 0.000000, bitrate: 24 kb/s
 Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1080x1920, 18 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
 Metadata:
 handler_name : VideoHandler
 vendor_id : [0][0][0][0]