Olivier Jeannet a écrit 1388 commentaires

Eh bien tu fais comme je dis, tu découpes ton film en 2 morceaux, un avant la pub et un après la pub, et tu les concatènes ensuite. Tu as les paramètres "-ss" pour le timing de début et "-to" pour le timing de fin, pour le découpage.
Accessoirement, je gagne du temps en créant les morceaux sur un ramdisk pour que ça aille plus vite (bon si tu fais tout sur un SSD NVME la différence doit être faible, mais on parle de gros fichiers de plusieurs Go).

Quand tu dis « Je convertis les fichiers pour réduire la taille des vidéos. Je les convertis vers du matroska H.264 », tu veux dire que tu refais de la compression H264 sur le fichier ".ts"/".m2t" ?
C'est une grosse perte de temps si tu fais ça, car c'est du H264 dans le flux ".ts"/".m2t".

Si tu utilises juste mkvmerge pour faire ça (pas besoin de Handbrake pour ça, ça se fait en une ligne de commande), ça va car ça change juste le conteneur et les métadonnées (et c'est très rapide), et effectivement un film ".m2t" transformé en ".mkv" avec mkvmerge est sensiblement plus petit (entre 10 et 20 % de différence), car le conteneur "mpeg-ts" a un surcoût relativement élevé, sauf erreur de ma part les flux sont découpés en paquets de 188 octets (pour faciliter la resynchro quand le signal n'est pas bon), là où en mkv les paquets doivent être nettement plus longs.

Le préfixe "en" est inutile et moche.
C'est en fait un anglicisme (peu importe si certains dictionnaires les mentionnent, c'est aussi dû au fait que les informaticiens ne sont pas les meilleurs en français, et les mainteneurs de dico pensent pouvoir leur faire confiance).
Et surtout je ne pige pas l'usage du terme "coder" pour de la compression vidéo qui est avec perte, vu que ce n'est pas un codage. Et personne ne dit qu'il "code en JPEG".

Pourquoi tu convertis les fichiers ts ? Tu les convertis en quoi d'ailleurs (conteneur et codec) ? Tu génères quel format avec handbrake (et avidemux même question) ? Si tu as des exemples de ligne de commande je suis preneur.
(Par ailleurs, je conclus de tes propos que handbrake et avidemux gèrent les sous-titres de type DVB, pour moi seul ffmpeg arrive à les gérer/conserver, et dans un conteneur de type ts/m2t)

Pour ma part, une fois vu un enregistrement
- soit c'est du français et je convertis (sans transcodage donc c'est rapide) en mkv (conteneur plus compact) avec mkvmerge en gardant le minimum (ce qui est le défaut, piste vidéo et 1ère piste audio)
- soit c'est de la VOST, et je reste en m2t et en mode copie (pas de transcodage/recompression) avec ffmpeg, je garde les 2 pistes audio (français et VO) et la piste de sous-titres normaux (dvb) ; quand il y a des pubs, j'en profite pour les enlever, en faisant un découpage hors pub puis un "concat" à la fin (cf un autre de mes commentaires).

PS : j'utilise Kaffeine pour enregistrer la TNT, depuis au moins 2014 (je ne sais plus ce que j'utilisais du temps de la télévision analogique et de ma carte d'acquisition Hauppauge, peut-être un bête "cat /dev/video/flux-mpeg >monfilm.mpg" (précédé sans doute d'une commande pour choisir la chaîne).

Pour ma part pour convertir des vidéos (et parfois les recompresser, en fonction de la source qui est peu compressée, et sans perdre en qualité), j'utilise ffmpeg, il n'y a pas besoin d'utiliser l'option "c:v libx264" car c'est par défaut, je me contente de préciser la vitesse/qualité avec "-preset" (en général "veryslow" en mode final, ça fait un fichier un peu plus petit que les autres modes, sachant que "ultrafast est facilement 2 fois plus gros).

J'utilise aussi le paramètre "-crf" pour la qualité, par défaut elle est de 23, et la doc dit que 17 ou 18 c'est quasi indistinguable de la source (mais ça augmente la taille bien sûr).

NB : merci d'éviter les affreux "encodage" et "encoder", vous pouvez parler à la rigueur de "codage" (encore que ça n'a pas de sens du fait qu'il y a perte), mais surtout de "conversion", "(re)compression" voire "transcodage" si vous voulez. Après tout, on ne dit pas qu'on "code en JPEG", en général on "convertit" ou on "sauve" en JPG. À noter aussi que codec = codeur/décodeur.

On avait déjà le multilingue dans certains car avec l'analogique et le NICAM (ou alors la stéréo, au minimum).

Depuis que la diffusion est en TNT (ou DVB en anglais), c'est du MPEG-TS avec plusieurs canaux additionnels, généralement il y a un ou deux canaux sonores supplémentaires (pour la VO et pour la version descriptive pour aveugles) et un ou deux canaux de sous-titres (un pour le sous-titrage sourds et un pour le sous-titrage "normal" moins complet pour quand on veut la VO).

Un canal des sous-titres est en fait constitué d'images et non de texte, sans doute pour que des bêtes téléviseurs puissent les afficher. Pour les téléviseurs pas trop vieux (ceux qui contiennent un ordinateur en pratique) on pourrait avoir un canal de vrais sous-titres (genre "srt") mais ça n'a pas été fait.

Je regarde la télé par l'antenne de toit et je doute être une minorité (et j'ai la fibre chez moi, dans une grande ville).
Effectivement, la proportion de geek qui comme moi ont un tuner TNT dans un ordi doit être relativement faible, mais il y a un marché vu qu'on trouve le matériel en vente (et pas qu'en France).

Pour falcaf qui disait « je crois que les fichiers .TS concernaient les flux SD ; avec la HD, les fichiers DVB sont devenus des .m2t » :
en fait c'est le même format, ".ts", ".m2t" et ".m2ts", c'est du MPEG Transport Stream (que le codec soit du MPEG-2 comme en TNT SD ou du MPEG-4 en TNT HD).

Tiens, un copain pour la TNT et de problème des sous-titres DVB.

J'ai depuis 2014 un mini-PC de salon sous XUbuntu pour enregistrer la TNT, j'ai commencé avec une carte PCI tuner TNT et puis j'ai ajouté une clé USB tuner TNT pour les soirs où pas mal de chaînes diffusent des choses intéressantes. J'ai ajouté un petit amplificateur de signal d'antenne. Il y a une semaine j'ai même ajouté une 2e clé USB tuner TNT, branchée avec un "T" en parallèle de la 1ère, le signal a l'air suffisant.

Avec tout ça, j'enregistre bien plus que ce que je peux regarder, entre les films et les documentaires et le reste. Pour la petite histoire j'avais commencé vers 2004 avec un mini-PC à base de CPU Via et une carte d'acquisition Hauppauge capable de transformer le SECAM en MPEG-2 directement, sous Linux bien sûr.

J'ai pas mal cherché pour la question du découpage des pubs et la conservation des sous-titres. Il a fallu attendre le support correct des sous-titres de type "dvb" par ffmpeg pour que ça fonctionne (il y a quelques années), en mode copie. Voici un exemple de ligne de commande pour conserver le 2e audio (VO) et les sous-titres DVB normaux (il y a aussi ceux pour sourds) :

avconv -i enreg.m2t -ss 0:05:03 -to 1:54:11 -map 0:v:0 -map 0:a:0 -map 0:a:1 -map 0:s:1 -c copy -y enreg_découpé.m2t

Pour enlever les pubs d'un enregistrement, c'est en notant les timings de début et de fin de pubs, je crée des morceaux de films hors pub ($time1 $time2 et $part changent au cours du script créé pour l'occasion) :

avconv -r 25 -i $source -ss $time1 -to $time2 -map 0:v:0 -map 0:a:0 -map 0:a:1 -map 0:s:1 -c copy -y $dest-$part.m2t

et ensuite je joins les morceaux, une commande réelle ressemble à ceci (à noter que j'ai ajouté "-r 25" car sans cela ffmpeg s'arrêtait en erreur sur certains flux) :

avconv -r 25 -i "concat:monFilm-p1.m2t|monFilm-p2.m2t|monFilm-p3.m2t" -map 0 -c copy -y monFilm-CUT.m2t

En faisant des recherches, j'ai vu qu'il y avait des méthodes plus ou moins simples pour transformer les sous-titres de type "dvb" en "srt", avec de l'OCR au passage, on trouve des exemple de commandes, mais je n'ai pas essayé. Avec ffmpeg on doit rester en m2t pour pouvoir conserver les flux "dvb", ça ne fonctionne pas vers mkv ou mp4.

En tous cas, mkvmerge ne permet toujours pas, à ma connaissance, de conserver les flux "dvb" en convertissant en mkv.

Zoom ne me branche pas trop notamment à vause de la barre du bas qui câche très souvent la barre Microsoft windows

Je n'ai pas le souci parce que je mets la barre sur le côté gauche, à la Ubuntu ; et c'est d'autant plus une bonne idée d'Ubuntu qu'avec ces stupides proportions 16:9 (pour l'informatique), on a trop en largeur et pas assez en hauteur. Et quand en plus on utilise un truc genre Word, qui comporte diverses épaisseurs en haut (rubans et autres menus) et en bas (barre de statut et autres), la zone de rédaction finit par être pas mal réduite. Donc la barre sur le côté, c'est très utile.

Merci pour ton commentaire, juste une remarque de forme :

UTF-8 est un format de codage (oui l'anglicisme me brûle les yeux à chaque fois, car on parle de codage d'information, codage de Huffman, message codé, etc.).

J'appelle ça les PALC (Proxies À La Con), cf cet article fondateur : https://www.padawan.info/fr/2007/09/le-proxy-a-la-con.html .
On trouve celui de Joël Ronez via webarchive : https://web.archive.org/web/20071223171647/http://blog.ronez.net/?p=708 .

Ça fait longtemps que je ne les utilise plus, mais pourquoi refaire un client XMPP alors que j'ai connu et utilisé entre autres : Gajim, Pidgin, Psi (qui faisaient plus que XMPP certes) ?

Je recommande la lecture de l'article sur la 5G (qui va bien au-delà de la question de la 5G), qui parle beaucoup de la perte de compétences (et de gestion interne des données) des opérateurs télécoms.

J'ai un disque externe de 2 To formaté en NTFS au cul de mon mini-PC de salon (xubuntu), j'y stocke mes enregistrements de la TNT et il est dans ce format pour que je puisse l'apporter chez des connaissances et le lire partout, même si c'est peu fréquent.

J'avais remarqué que l'occupation CPU n'était pas négligeable, alors qu'il est encore sur un port USB 2 donc limité à 35 M/s, et j'ai un peu creusé. J'ai donc ajouté une entrée dans la fstab, en m'inspirant des valeurs issues du montage automatique, et en rajoutant le mot-clé big_writes aux options.

Elle permet de passer les transferts de buffers de seulement 4 k (par défaut à cause de FUSE) à des buffers de 128 k, et ça joue clairement sur le CPU (un Celeron Ivy Bridge à 1,8 GHz) ; c'est indiqué dans le man de ntfs-3g. Le jour où je passe à l'USB 3 côté ordinateur je pourrai aussi voir si ça joue sur la vitesse absolue, le disque étant déjà USB 3.
En tous cas ça permet de constater qu'ext4 est assez performant côté CPU, je crois qu'il a toujours été meilleur que les autres FS.

Pour ma part sur le disque système (sur mes machines) j'utilise toujours le paramètre "-m 1" parce que j'estime que 1 % de 6 Go c'est déjà pas mal pour dépanner, si jamais le "/" est plein pour l'utilisateur.

Il me semble que la taille d'un inode est indiquée quand on utilise par exemple "dumpe2fs /dev/sdX1", et c'est pour mon disque système en ext4 :
Inode size: 256

C'est un ancien collègue, je ne suis pas certain qu'il ait un FB et je n'ai pas son téléphone.
Dans tous les cas, mon bref message ne justifie pas un "moinssage", surtout que le journal n'est plus tout neuf. Franchement, ça ne me viendrait pas à l'idée.

Comment peut-on moinsser un message de ce type ?

Franchement il y a des gens pas nets…

Bel effort de recherche :-) .
Cela dit, ça reste quelque chose de purement américain, nous autres européens, sans activité aux US, ne sommes pas concernés par ces brevets logiciels. Le fait est que sous Linux on n'a pas le souci (corrige-moi si je me trompe).

Bonne année Denis (je suis tombé sur ton journal via la dépêche "les mieux notés"), et je te souhaite bonne guérison en particulier.

JPEG ok, lui il a encore des revendications de brevet associées

Des brevets sur le JPEG ?
Premièrement, ça ne vaudrait qu'aux US, et deuxièmement, ça concerne j'imagine que la compression/codage arithmétique, qui du coup n'a jamais été employée.
De toutes façons, on dispose de la libjpeg depuis tellement longtemps, peu importe les histoires de brevets US.

j'ai tendance à pouffer sur le Qui est prêt pour le desktop ?

Haha bien vu :-) .

J'ai découvert il y a longtemps le clavier x-fr-latin9 (super aussi pour taper les guillemets français « » ) mais comme l'a dit quelqu'un on n'est pas toujours admin sous son poste Windows.

(PS : j'ai beau être tout ce qu'il y a d'expérimenté en bash (et tous les petits programmes genre awk sed et compagnie) et en d'autres langages, c'est quand même vachement mieux d'éviter les espaces dans les noms de fichiers parce que de temps à autre ça complique inutilement les recherches que je fais.

Je ne conseille l'absence d'espace que si quelqu'un veut utiliser des scripts ou faire des commandes rapides en bash. Si je mets un nouveau sous Linux je lui dis que ça peut être plus pratique d'éviter les espaces, après ce n'est pas une contrainte s'il n'utilise jamais la ligne de commande.

Je me sers aussi de l'interface graphique quand c'est plus pratique que la ligne de commande, mais quand tu vois le nombre de gens qui ont installé Cygwin rien que pour pouvoir utiliser la ligne de commande pour des petites manips, c'est qu'il y a un besoin. Et là, les espaces font vite ch*er alors que franchement avoir des " _ " dans les noms à la place des espaces je vois pas le souci, d'ailleurs j'utilise régulièrement la commande « rename 's/ /_/g' toto* tata* » quand j'ai récupéré des fichiers avec des espaces (exemple typique avec youtube-dl sur les replay TV), c'est vite réglé.

Sinon on est d'accord que la machine doit s'adapter à l'homme, mais la solution aux espaces dans les noms de fichiers et les petites manips en bash n'est pas encore satisfaisante.

Je n'ai pas "moinssé" ton commentaire mais je cherche encore le rapport entre le fait que Linux n'a pas encore pris sur le Desktop, et le fait de préférer mettre des "_" dans les noms fichiers quand on est utilisateur.

Par ailleurs je viens d'y penser, sur les sites de téléchargement (et sur la Mule) étrangement les espaces sont remplacés non pas par des "_" mais par des ".", exemple : Weeds.6x13.Theoretical.Love.Is.Not.Dead.Vostfr.Hdtv-Ghost-Team.avi . Finalement les Windowsiens (très forte majorité d'utilisateurs de ces sites) savent remplacer les espaces quand ça facilite le fonctionnement :-) .

"Sérieux si en 2016 tu n'es pas capable de gérer un nom de fichier avec un espace, c'est grave"

Ça dépend de ce qu'on appelle gérer, sous Linux ça peut passer avec des guillemets (comme sous Windows pour une commande "Dir") en shell, mais je ne mets jamais d'espace dans un nom de fichier, je les remplace par des "_" qui sont faits pour ça (sinon à quoi sert ce caractère d'ailleurs ?).

Quand on est un habitué de la ligne de commande pour faire des recherches ou des mini-traitements, avec par exemple des "find" ou des "locate" qui sont tubés (pipe) dans une commande qui suit, les espaces très franchement c'est ch*ant (même si en écrivant ses scripts ou commandes d'une certaines façon ça peut passer).