Du vrai 819 lignes : la solution !

[Mannix54]

@Clopos

Je vais faire les mises à jour préconisée et voir si cela change le problème…
PS : je bloque car je ne sais pas mettre à jour → update libhackrf et hackrf-tools.

c’est le paquet libhackrf-dev qu’il faut mettre à jour :

sudo apt-get update sudo apt-get install libhackrf-dev

mais le paquet n’a peut-être pas été encore mis à jour chez les distributions de type debian/ubuntu/raspberry OS, il est peut-être encore en version 2018.01,

pour mettre à jour le firmware du hackrf :
github.com/mossmann/hackrf/wiki … g-Firmware

hackrf_spiflash -w hackrf_one_usb.bin

c’est un fichier hackrf_one_usb.bin à prélever dans le code source d’hackrf disponible sur le github, il est dans un sous-répertoire « firmware-bin » :
github.com/mossmann/hackrf/rele … 1.03.1.zip

En lançant l’utilitaire hackrf_info dans une console on peut connaitre la version du firmware actuellement installée.

Dans le doute, si on est pas certain de comprendre la procédure alors il vaut mieux renoncer à la mise à jour du firmware, pour éviter de « briquer » son hackrf (comme pour un flashage de bios de carte mère qui se passerait mal).

[Clopos]

@Mannix54

le paquet n’a peut-être pas été encore mis à jour chez les distributions de type debian/ubuntu/raspberry OS, il est peut-être encore en version 2018.01,

Hello,
Merci pour les conseils.
Effectivement, j’ai réussi la première étape mais je reste en version 2018.01.

Pour le moment, je vais me garder de procéder à la mise à jour du firmware, sauf s’il existe une solution plus simple sous Windows 10 (j’utilise cette version avec l’émulateur VirtualBox sur mon mac).

Ou encore, si j’installe une version Linux mieux adaptée au HackRF via VirtualBox… ?

[Clopos]

Hello,

Précision importante quand au problème de décrochage synchro subi :
En regardant la partie non visible de l’image vidéo, quand survient le problème de désynchronisation, j’observe que cette section normalement noire se remplit de lignes blanches, ce qui probablement affecte la détection de trame/ligne et ce qui perturbe le téléviseur.

[Mannix54]

Faire tourner hackrf dans une machine virtuelle ça peut créer des problèmes, car les machines virtuelles ont du mal à gérer de manière efficace le port USB, le débit sera moins rapide par rapport à un système d’exploitation installé physiquement sur un PC.

extrait de la FAQ d’hackrf :

Why doesn’t HackRF work properly with a virtual machine (VM)?

HackRF requires the ability to stream data at very high rates over USB. Unfortunately VM software typically has problems with continuous high speed USB transfers.

There are some known bugs with the HackRF firmware’s USB implementation. It is possible that fixing these bugs will improve the ability to operate HackRF with a VM, but there is a very good chance that operation at higher sample rates will still be limited.

et pour la nécessité d’avoir un CPU assez puissant :

What are the minimum system requirements for using HackRF?

The most important requirement is that you supply 500 mA at 5 V DC to your HackRF via the USB port. If your host computer has difficulty meeting this requirement, you may need to use a powered USB hub.

Most users will want to stream data to or from the HackRF at high speeds. This requires that the host computer supports Hi-Speed USB. Some Hi-Speed USB hosts are better than others, and you may have multiple host controllers on your computer. If you have difficulty operating your HackRF at high sample rates (10 Msps to 20 Msps), try using a different USB port on your computer. If possible, arrange things so that the HackRF is the only device on the bus.

There is no specific minimum CPU requirement for the host computer, but SDR is generally a CPU-intensive application. If you have a slower CPU, you may be unable to run certain SDR software or you may only be able to operate at lower sample rates.

github.com/mossmann/hackrf/wiki/FAQ

[Clopos]

@brunopif

Voilà, j’espère que ce code est bon, il me manque les durée de lignes et les marges car je ne retrouve plus les caractéristiques du 441 lignes.

Hello,
Est-ce que cette page wikipedia peut aider ?

Voir aussi dans sa rubrique « discussion » :
https://en.wikipedia.org/wiki/441-line_television_system

[Clopos]

Hello à tous,

Effectivement, quand le dysfonctionnement de synchro apparaît, la lettre U est générée dans la console : UUUUUUUUUUUUUUUUUUUUU…

@Bruno
J’observe que quand j’ajoute la suppression de chroma dans le code hacktv, la vidéo devient alors plus stable en noir et blanc, tant en B/G, qu’en modulation L.

EDIT : j’ai découvert un moyen provisoire d’obtenir une vidéo fluide et en couleur !

Malheureusement, il s’agit alors de supprimer l’audio. Lorsque j’effectue cette commande, le phénomène de décrochage n’apparaît plus. Je pense que cela doit provenir d’une incompatibilité dans la librairie ffmpeg et l’interprétation par HackTV… Le problème ne provient donc pas dans la capacité hardware / middleware du chipset ou du PC.

Parfois avec certaines vidéos, en supprimant la couleur (-v --nocolour), cela peut fonctionner mais hélas au détriment de la chroma.

La mention à ajouter doit donc être :
-v --noaudio

[marceljack]

@Clopos

EDIT : j’ai découvert un moyen provisoire d’obtenir une vidéo fluide et en couleur !

Malheureusement, il s’agit alors de supprimer l’audio. Lorsque j’effectue cette commande, le phénomène de décrochage n’apparaît plus. Je pense que cela doit provenir d’une incompatibilité dans la librairie ffmpeg et l’interprétation par HackTV… Le problème ne provient donc pas dans la capacité hardware / middleware du chipset ou du PC.

Parfois avec certaines vidéos, en supprimant la couleur (-v --nocolour), cela peut fonctionner mais hélas au détriment de la chroma.

La mention à ajouter doit donc être :
-v --noaudio

Bonjour,
Cela semble le signe d’une intermodulation entre la chroma, l’audio et la luminance.
Signe d’une non linéarité dans le processus de modulation (numérique).

Est-il possible de diminuer l’amplitude des (sous)-porteuses audio et chroma ?

[Mannix54]

@Clopos

Malheureusement, il s’agit alors de supprimer l’audio. Lorsque j’effectue cette commande, le phénomène de décrochage n’apparaît plus. Je pense que cela doit provenir d’une incompatibilité dans la librairie ffmpeg et l’interprétation par HackTV… Le problème ne provient donc pas dans la capacité hardware / middleware du chipset ou du PC.

Quand tu vois du « UUUUUU » qui augmente en longueur de manière infinie sur la console c’est souvent un problème de matériel qui ne suit pas la cadence demandée par hacktv (CPU, bande passante du port USB),

si tu penses que ça vient de ffmpeg qui prend trop de ressources CPU au point de ralentir la machine : essaie de recompresser la vidéo avec un codec audio et vidéo moins consommateur, de redimensionner la vidéo vers du 576p, et de re-échantilloner le nombre d’images par seconde à 25, c’est faisable avec le logiciel avidemux et les codecs et filtres appropriés.

Un codec vidéo comme le h264 AVC (ou plus léger comme du mpeg2), de l’audio comme du mp3 et le conteneur mkv devraient donner une bonne expérience avec hacktv.

Si le problème persiste même en utilisant la mire de test intégrée à hacktv alors le CPU n’est peut-être pas assez rapide pour hacktv.
Quand tu utilises la mire de test de hacktv avec un hackrf alors par défaut un son de 1000 hertz est généré en même temps que la mire, on doit pouvoir l’entendre sur le poste de TV si la réception est bonne.

[Mannix54]

J’ai mis un fichier vidéo de type 576p, 25 fps, codec h264 AVC et son mp3, il serait intéressant que Clopos teste avec son hackrf :
we.tl/t-mNOTvE66BB

[Clopos]

Bonjour Mannix54,

J’ai procédé à plein de tests avec tous types de fichiers, y compris celui que tu as mis à dispo.

Le phénomène est strictement le même et je suis à peu près certain que cela ne concerne pas la partie vidéo - pourtant particulièrement bien plus vorace en ressources que l’audio - car c’est systématique, dès lors que je demande à HackRF d’ignorer l’audio, je n’ai strictement plus aucun problème de synchro ou d’erreurs (fameux « UUU… » ), tant en PAL, qu’en Sécam (version initiale incorrecte bien sûr).

Des vidéos les plus complexes en 1080p50 aux plus basiques 576i25, le souci est exactement le même. Seule une vidéo récupérée sur le web mais encodée à 23,97i/s fonctionne en modulation i PAL mais pas en L Sécam, sauf en ignorant l’audio.

J’ai également transcodé uniquement les pistes audio en AAC ou en AC3 et le résultat reste le même pour tous les fichiers.

De ce fait, le souci ne provient pas de la bande passante USB mais bien d’un bug ou d’une mauvaise config dans les éléments firmware ou soft que j’exploite actuellement.

Idée : certains players sont parfois désorientés parce que la cadence image (exemple à 25i/s) est différente de la cadence audio (exemple à 23,97i/s). VLC sait corriger ce problème et conserver la synchro mais d’autres, non.

La suggestion de marceljack est également pertinente. Au moment du mélange numérique/analogique des modulations, l’audio mal géré semble bien venir perturber le signal vidéo…

Avec la version que j’utilise, je n’ai d’ailleurs pas pu lancer l’utilitaire :
hackrf_transfer -r /dev/null -s 20000000
permettant justement d’éprouver la BP de l’USB…

Pour le reste, j’ai réussi à exploiter les fonctions radio, y compris directement sur mon Mac (MacOS). Cela fonctionne très bien, notamment sur la bande FM : 87 à 108 MHz.

L’idéal consisterait à ce que j’exploite Linux en virtuel juste pour faire la mise à jour Firmware de la carte HackRF. Mais quelle distribution utiliser dans l’idéal ? Debian ?

[marceljack]

Bonjour Clopos,
Est-ce que ce ne serait pas de l’intermodulation au niveau de l’étage d’entrée du téléviseur à cause d’un niveau trop élevé ?
As-tu essayé de mettre un atténuateur de 20 à 30 dB entre le hackRF et l’entrée antenne du TV ?
Ou sur l’antenne réceptrice si tu reçois « sans fil » ?

[Clopos]

@marceljack

Bonjour Clopos,
Est-ce que ce ne serait pas de l’intermodulation au niveau de l’étage d’entrée du téléviseur à cause d’un niveau trop élevé ? As-tu essayé de mettre un atténuateur de 20 à 30 dB entre le hackRF et l’entrée antenne du TV ?
Ou sur l’antenne réceptrice si tu reçois « sans fil » ?

Hello marceljack,

Non, j’ai exploité différents niveau de sortie HF (c’est d’ailleurs très simple à faire avec HackTV).

De plus, j’utilise une antenne d’émission et aucune liaison directe (déconseillée).

Quand le souci se produit, je dérègle volontairement le balayage sur le TV et je vois bien toutes les lignes blanches remplacer celles qui sont noires d’habitude et venir perturber les lignes de synchro trame. C’est bien dans le signal composite que cela se produit et non dans la modulation.

[marceljack]

@Clopos

C’est bien dans le signal composite que cela se produit et non dans la modulation.

C’est surprenant qu’il y ait interaction entre le son et l’image au niveau de la vidéo composite …

[Clopos]

@marceljack

@Clopos

C’est bien dans le signal composite que cela se produit et non dans la modulation.

C’est surprenant qu’il y ait interaction entre le son et l’image au niveau de la vidéo composite …

Cela relève probablement d’un bug de type « overflow » au moment de la gestion vidéo + audio + synchro. J’ai déjà rencontré ce type de phénomènes étranges avec des transcodeurs professionnels (software), notamment avec ATEME Titan.

Mais c’était pour des fichiers sortis en HEVC H.265 bien plus complexes.

EDIT : peut-être quelques indices ci-dessous, sur le problème rencontré…

Audio / Vidéo / Sync :
github.com/fsphil/hacktv/issues/10

Autre bug (niveau Sync) :
github.com/fsphil/hacktv/issues/24

Macrovision :
github.com/fsphil/hacktv/issues/44

[Mannix54]

@Clopos

Bonjour Mannix54,

J’ai procédé à plein de tests avec tous types de fichiers, y compris celui que tu as mis à dispo.

Le phénomène est strictement le même et je suis à peu près certain que cela ne concerne pas la partie vidéo - pourtant particulièrement bien plus vorace en ressources que l’audio - car c’est systématique, dès lors que je demande à HackRF d’ignorer l’audio, je n’ai strictement plus aucun problème de synchro ou d’erreurs (fameux « UUU… » ), tant en PAL, qu’en Sécam (version initiale incorrecte bien sûr).

1. est-ce que tu observes le souci lorsque tu utilises que la mire intégrée à hacktv ?
   Notamment lorsque tu tapes cette commande exacte pour générer du PAL G sur le canal 31 ? (n’ajoute pas d’autres options dans la ligne de commande) :

hacktv -f 551250000 -m g -g 44 test

2. Quel matériel utilises-tu exactement ?
   Un imac avec son système d’exploitation ?
   Un imac sur-lequel tu utilises une machine virtuelle pour le hackrf (attention la bande passante USB sera réduite avec une machine virtuelle) ?

La configuration conseillée est un PC sous linux (ou à la rigueur un raspberry pi 4), idéalement ubuntu avec les bons paquets à jour pour le hackrf et hacktv.

Il faut oublier la machine virtuelle, car le hackrf n’aime pas du tout être utilisé dans une machine virtuelle (risque élevé de bugs USB, bande passante réduite), il lui faut un OS en natif qui lui permettra d’avoir la garantie de bonnes performances sur le port USB,

dans un premier temps il faut faire en sorte que les outils de diagnostic du hackrf fonctionnent, notamment la commande suivante :

hackrf_transfer -r /dev/null -s 20000000

ça doit générer cette sortie avec un PC sous linux et un port USB 2.0 :

call hackrf_set_sample_rate(20000000 Hz/20.000 MHz) call hackrf_set_hw_sync_mode(0) call hackrf_set_freq(900000000 Hz/900.000 MHz) Stop with Ctrl-C 39.8 MiB / 1.000 sec = 39.8 MiB/second 40.1 MiB / 1.000 sec = 40.1 MiB/second 39.8 MiB / 1.000 sec = 39.8 MiB/second 40.1 MiB / 1.000 sec = 40.1 MiB/second 40.1 MiB / 1.000 sec = 40.1 MiB/second 39.8 MiB / 1.000 sec = 39.8 MiB/second 40.1 MiB / 1.000 sec = 40.1 MiB/second

si la commande fonctionne alors normalement tout sera ok avec hacktv (version récente du github, celle que j’avais installé sur ton rasbperry pi par exemple).

Il faudrait aussi lancer un « hackrf_info » pour connaitre la version du firmware installée.

[Mannix54]

autre piste :

• désactiver l’option nicam avec hacktv, par défaut en pal et en secam il envoie le son en nicam, ça peut poser problème avec certains TV, notamment anciens.

Pour désactiver le nicam tu ajoutes l’option « –nonicam » à la ligne de commande de hacktv, le son sera alors en mono.

--nonicam   Disable the NICAM subcarrier if present.

Si ça ne résout pas le problème : alors faire en sorte que l’outil de test « hackrf_transfer » fonctionne sans erreurs (cf mon message précédent), notamment avec un taux d’échantillonnage de 20 MHz, ça démontrera que le port USB n’est pas bridé et que tout est ok au niveau pilote et firmware du hackrf.

[Clopos]

@Mannix54

1. est-ce que tu observes le souci lorsque tu utilises que la mire intégrée à hacktv ?
   Notamment lorsque tu tapes cette commande exacte pour générer du PAL G sur le canal 31 ? (n’ajoute pas d’autres options dans la ligne de commande) :

hacktv -f 551250000 -m g -g 44 test

Hello,
Cela fonctionne bien en modulation G (ou i) mais cela décroche avec la modulation L sauf si j’ajoute --noaudio.

@Mannix54

2. Quel matériel utilises-tu exactement ?
   Un imac avec son système d’exploitation ?
   Un imac sur-lequel tu utilises une machine virtuelle pour le hackrf (attention la bande passante USB sera réduite avec une machine virtuelle) ?

Non, pour HackTV, je n’utilise que le Raspberry Pi 4 que tu as configuré avec le module HackRF One.
Je ne pense pas que Ubuntu (fiable ?) soit installable sur cette machine.
Je n’utilise mon mac que pour l’application radio, qui fonctionne très bien.

@Mannix54

Dans un premier temps il faut faire en sorte que les outils de diagnostic du hackrf fonctionnent, notamment la commande suivante :

hackrf_transfer -r /dev/null -s 20000000

J’ai déjà précisé dans un précédent post que cela ne fonctionne pas, j’obtiens :
« bash: hackrf_transfer : commande introuvable »

@Mannix54

Il faudrait aussi lancer un « hackrf_info » pour connaitre la version du firmware installée.

idem : commande introuvable.

[quote=« Mannix54 »]
autre piste :

• désactiver l’option nicam avec hacktv, par défaut en pal et en secam il envoie le son en nicam, ça peut poser problème avec certains TV, notamment anciens.[/code]

Bingo ! C’était probablement ça car cela semble résolu, le Nicam prenait manifestement trop de place.

Merci encore.

Questions subsidiaires :

• comment « quitter » le process sans quitter la console ? J’ai tenté « exit », « quit », etc… sans succès. Cela m’oblige à relancer à chaque fois.
• comment augmenter le volume sonore qui tout particulièrement en AM (norme L) est assez faiblard ?

[Mannix54]

Pour les outils hackrf essaie d’installer le paquet hackrf :

sudo apt-get install hackrf

tu auras alors les outils manquants de diagnostic :

hackrf_clock hackrf_cpldjtag hackrf_debug hackrf_info hackrf_operacake hackrf_spiflash hackrf_sweep hackrf_transfer

La piste du nicam qui perturbe ton vieux TV en mode secam L me semble de plus en plus plausible, essaie de faire un test en désactivant le nicam (option --nonicam), le son sera alors en mono.

[Clopos]

@Mannix54

La piste du nicam qui perturbe ton vieux TV en mode secam L me semble de plus en plus plausible, essaie de faire un test en désactivant le nicam (option --nonicam), le son sera alors en mono.

Hélas, cela ne fonctionne qu’avec certains fichiers vidéo et pas d’autres. Ce qui fonctionne tout le temps est --noaudio.

[Mannix54]

@Clopos

Questions subsidiaires :

• comment « quitter » le process sans quitter la console ? J’ai tenté « exit », « quit », etc… sans succès. Cela m’oblige à relancer à chaque fois.
• comment augmenter le volume sonore qui tout particulièrement en AM (norme L) est assez faiblard ?

Pour quitter hacktv sans fermer la console : c’est la combinaison de touches « ctrl + c » (contrôle c).

Pour augmenter le volume : je crois pas qu’il y ait d’option pour cela dans hacktv, je pense qu’il faut alors modifier le fichier vidéo avec avidemux, pour éditer la piste audio afin d’augmenter le volume avec un filtre audio.