Longtemps attendue, la nouvelle version est majeure. Baptisée Lorentz, elle passe un coup de balai conséquent sur des dizaines d’API marquées comme « dépréciées » depuis longtemps, mais qui étaient toujours présentes dans la version 4.4.
La mouture 5.0 s’en défait. Jean-Baptiste Kempf, président de VideoLan, parle dans un billet dédié de 80 commits de suppression intégrés dans la branche principale du projet en avril dernier. Un important travail, d’autant que certaines API étaient toujours utilisées en interne.
Parmi les nouveautés propres à FFmpeg, on peut citer une nouvelle API unique pour l’audio et la vidéo ainsi que des codecs séparés pour l’entrée et la sortie dans avcodec, une API basée sur AVFrame dans swscale, une nouvelle API pour le filtrage bitstream, plusieurs nouveaux décodeurs (dont MSN Siren, GEM Image et Apple Graphics), d’importantes améliorations pour Vulkan ou encore une série de nouveaux filtres.
La version 4.4 reste supportée, car Lorentz introduit de nombreux changements pouvant entrainer des cassures. À moins, comme le précise Jean-Baptiste Kempf, que les développeurs aient suivi de près les commits dans le projet et aient adapté leur code, notamment en retirant les appels aux API dépréciées.
Toujours selon Kempf, cette version 5.0 pourrait devenir LTS. Il espère, dans le sillage de cette sortie, que le développement de FFmpeg aura maintenant un agenda clair, avec une version par an, dont une sur deux LTS.
Commentaires (14)
#1
Quel lien existe-t-il entre Videolan et FFmpeg, hormis le fait que VLC utilise les librairies de FFmpeg en interne ?
Car a ma connaissance, Jean-Baptiste Kempf n’est pas lié à ce projet (ou j’ai zappé l’info) mais est quand même cité 3x dans la news tandis que le site de FFmpeg… n’est pas cité ! Du coup, cela donne l’impression qu’il fait partie de l’équipe alors que je ne crois pas que cela soit le cas. (Attention, je ne dis pas qu’il ne peut pas y avoir des contributions, juste que la maintenance n’est pas gérée par VideoLan ni JBK)
Et concernant le LTS, de ce que je comprends, c’est un souhait d’un utilisateur, pas le reflet de la politique de ceux qui gèrent FFmpeg.
#1.1
Peut être parce que l’article est basé sur le post de JBK
#2
A contrario, sur les trois liens de la brève, deux pointent sur le site de FFmpeg.
#3
#3.1
J’avoue que je n’ai jamais étudié les possibilités de CLI de VLC
#4
C’est le cas de tout ce qui doit posséder des tonnes de paramètres (dont certains venant de plugins). Et en encodage vidéo il y en a toujours eu des tonnes, et que ce soit en CLI ou GUI, sous Linux ou Windows, il y a toujours eu des logiciels compliqués avec des options partout. Il y a eu aussi plein de logiciels plus simples mais forcément qui décident pour toi de ce qui est bien, suivant les goûts du développeur. A chacun de choisir.
Pour utiliser les 2 en CLI, je trouve que ça reste compréhensible (et l’ordre choisi pour les paramètres joue beaucoup là-dessus) mais il vaut mieux partir d’exemples déjà fonctionnels et les customiser ensuite, plutôt que de s’attaquer direct aux docs pour créer une ligne de commande fonctionnelle de toutes pièces.
#5
idem. Pour ffmpeg, vive stackoverflow \o/. Bon y a 8 réponses différentes pour un même problème, mais on finit par trouver son bonheur.
Pour VLC, j’avoue ne jamais avoir compris comment on passe de “
--sout-transcode-venc=...” dans la documentation CLI à “--sout='#transcode{...}'” dans l’exemple.#6
#7
BluRay 4k ? Vidéos 8k HDR, non mais !
Pour FFmpeg, c’est un outil magique, comme imagemagick pour les images, et vive les prises de tête avec la CLI dans les 2 cas
#7.1
Oui je pensais aussi à imagemagick c’est puissant mais faut bien comprendre comment ça marche est que l’ordre des params est crucial.
L’avantage est que tu n’as pas vraiment de limites tout est possible. EN général ce genre de commande je le fais dans un fichier texte (une ligne une action), quand j’y crois j’enlève les retours chariot et colle dans le terminal :yolo:
#8
C’est pour ça que je me suis fait un pense-bête dans un fichier texte, avec des exemples pris ça et là pour : reconstituer un fichier vidéo à partir de l’URL d’une playlist M3U8, convertir une vidéo musicale YouTube MP4 en fichier son MP3, réencoder une vidéo en y gravant des sous-titres en hardsub, réduire le débit d’images d’une vidéo à 60 FPS vers du 30 FPS (sans réduire la durée de la vidéo), réparer le format d’une vidéo (du 4⁄3 qui devrait être du 16⁄9), retourner une vidéo à 90° (peste soit des gens qui filment en mode portrait avec leurs spyphones !
)…
#9
Pareil. Pas facile sinon :-) .
Au fait, pourquoi convertir la vidéo avec les sous-titres en dur ? Je trouve que c’est mieux d’avoir les sous-titres en optionnel, stockés dans la vidéo dans un flux dédié (et surtout ça gagne le temps de reconversion).
Tu fais ça en reconvertissant la vidéo, ou bien juste en changeant les quelques octets du fichier qui décrivent la proportion ?
Avec VLC en tous cas, la touche qui faire boucler à travers les différents aspects connus m’est parfois bien utile.
Bien d’accord !
#10
Parce que ce sont des vidéos que je veux regarder sur ma télé (81 cm, c’est plus confortable que le PC portable 15,6”), et que celle-ci ne sait pas lire les ST en softsub quand je lui fais lire les vidéos depuis une clef USB. Donc, pas le choix.
Avant, je passais par Chromecast, mais les vidéos avaient la sale tendance à se figer pendant que le son continuait quelques secondes, puis lui aussi se coupait, puis tout reprenait avec l’image qui « rattrapait » son retard en mode avance rapide, avant que ça ne recommence quelques secondes plus tard (et c’était pas un problème de connexion faiblarde). Au bout d’un moment, j’en ai eu marre et le seul ennui, maintenant, c’est que je fais turbiner le Core 2 Quad du PC fixe à fond pendant 20 minutes pour graver ces fichus ST en hardsub, pour une vidéo qui en dure 25 ou 30.
Et comme elle ne lit pas non plus très bien les vidéos en 60 FPS, je passe aussi par FFMpeg pour convertir celles que je récupère ainsi en 30 FPS. Là, c’est environ la moitié du temps de la vidéo que ça prend pour être fait.
Après, c’est du « jetable » : une fois les vidéos vues, je les vire (sauf rares exceptions).
#11
Merci pour les explications.
Détail, un autre avantage d’avoir les sous-titres dans un flux texte dédié c’est de garder la qualité initiale de la vidéo (je ne sais pas dans quelle mesure une recompression peut être neutre si c’est à qualité égale (ou supérieure).
Je viens de penser à une chose, dans le flux de la TNT (.m2t/.m2ts = MPEG-TS) les sous-titres sont en fait des images, pas du texte ; en tous cas le type de flux des sous-titres est traitable par ffmpeg (pour l’inclure ou l’exclure) pour re-sauver en “.m2t” mais mkv ne reconnaît pas ce type de sous-titres, alors qu’il reconnaît bien les pistes audio supplémentaires. Dommage car la conversion du conteneur m2t vers mkv a 2 avantages, elle prend sensiblement moins de place (étonnant mais je crois que le MPEG-TS a des méta-données bien plus fréquemment, pour la synchronisation en réception), et rend le “seek” avec VLC instantané et parfait en rendu, là où c’est un peu plus lent et pas toujours parfait (macroblocs pas convertis au début) en m2t.
(du coup je viens de penser à un truc tout bête, je n’ai pas regardé si les versions récentes de ffmpeg peuvent faire la conversion en mkv, et du coup conserver les sous-titres)
De ce que j’ai déjà vu en googlant, pour convertir les sous-titres de ces fichiers “.m2t”, il faut passer par de l’OCR sur le canal des sous-titres… ça marche peut-être assez bien mais je ne me suis jamais lancé là-dedans.