Les fichiers qui marchent tout le temps avec l’option --nonicam : ce sont les fichiers simple résolution 576p à 25 fps ?
Il serait interessant de voir si le problème n’a lieu qu’avec les fichiers haute résolution, le CPU du raspberry pi est peut-être trop léger pour un fonctionnement de ffmpeg sur des fichiers HD (saccades en lecture pour les fichiers HD si l’accélération du GPU n’est pas utilisée, du coup ça peut faire ramer hacktv et créer des « UUUUUU »).
Non, hélas.
Le fichier que tu as transmis ne fonctionne pas, ni en G PAL, ni en Sécam L.
Un gros fichier en 1080p50 fonctionne lui très bien avec nonicam en PAL G mais pas en Sécam L.
Je pense que ce n’est pas corrélé à la vidéo (sauf la partie synchro) car même avec la mire « test » intégrée de HackTV, quand je choisis --nonicam ou --noaudio, le résultat est bon en modulation L.
Ça peut être juste une histoire de codec audio mal supporté par ffmpeg, sur le fichier que je t’ai fourni la piste était en mp3,
mais bizarre que ça ne marche pas en PAL G alors qu’avec d’autres fichiers vidéos ça fonctionne, il y a quelque chose de pas clair là dedans, peut-être la version du paquet ffmpeg qui est bogué dans le raspberry pi, moi je suis sous archlinux, ce n’est pas la même version de la librairie ffmpeg (qui est beaucoup plus récente sous archlinux).
Je pense que lorsque tu utilises la mire intégrée à hacktv ffmpeg est zappé pour la partie audio, ou du moins le son est généré autrement, sans recours à un codec audio (du 1000 Hz), peut-être pour ça que le bug n’existe pas via cette mire intégrée.
Le SECAM L n’est pas bien supporté dans hacktv, il y a des bugs qu’on avait identifié (chroma en retard sur la luma), il est très possible qu’il y ait aussi des bugs liés au son (nicam, et peut-être même le son mono), un signal SECAM L pas tout à fait standard généré par hacktv, ça passe sur certains TV, pas sur d’autres comme le tien
pour info sur une carte tuner winfast DTV1800H j’avais remarqué aussi des soucis de son en SECAM L avec hacktv : son faiblard, voire parasité, en désactivant le nicam c’était un peu mieux, mais pas parfait, en PAL B/G le son était bien meilleur (y compris en nicam).
Sinon pour le résultat du test hackrf_transfer tes chiffres sont ok, on est sûr maintenant que le port USB n’est pas bridé.
Pour certains d'entre vous dont le pc possède un port Mini-PCIE, il existe cette carte:
[url]https://www.passion-radio.fr/emetteur-sdr/fairwaves-sdr-937.html[/url]
Mais je ne sais pas ce que cela vaut en termes de fonctionnement sous Linux.
Rubrique SDR:
[url]https://www.passion-radio.fr/radio-logicielle-sdr/22[/url]
[url]https://www.ouverture-fine.com/recherche[/url] (mot-clé: SDR)
J’ai enfin réussi à updater le firmware du HackRF One. Cela ne solutionne pas tout mais cela a l’air plus fiable. L’audio AM en modulation L est bien meilleur.
Mais pas vraiment de changement notable sur l’instabilité avec audio, notamment pour la modulation L.
Je n’ai pas testé sur un TV LCD mais uniquement sur un petit téléviseur cathodique couleur. Je vais voir ça demain.
Effectivement, cela a l’air d’être une histoire de bug dans la synchro audio et la synchro vidéo. La puissance du chipset ou la liaison USB ne sont pas en cause.
En tout cas, on a trouvé un contournement partiel qui marche tout le temps (sans audio), une solution qui fonctionne parfois (sans nicam), la solution pour la mise à jour FW et des pistes pour avancer…
Tout d’abord merci de m’avoir aiguillé ces derniers mois concernant la solution HackTV et le 819 lignes !
Il y a un autre fil concernant l’appareil (voir ci-dessous). Je me demande si nous ne devrions pas en créer un autre plus spécifique qui traiterait de tous types de normes et standards pour l’appli HackTV : 819 lignes, modulation L, Sécam et 441 lignes… ? http://forum.retrotechnique.org/viewtopic.php?f=15&t=256984
Après si tu as un autre PC plus puissant que le raspberry pi il sera intéressant de tester aussi, car on sait que le raspberry pi 4 a une gestion du CPU en mode économie d’énergie (pour éviter qu’il chauffe trop la fréquence CPU peut faire le yoyo), sur un PC fixe il n’y aura pas ce souci.
Je sens qu’il y a plusieurs bugs combinés, un SECAM-L non standard généré par hacktv quand de l’audio est incorporé, avec des tuners TV qui peuvent réagir différemment selon leur marge de tolérance, et un possible manque de puissance aléatoire du raspberry pi quand certaines conditions sont réunies (la mention « UUUUU » qui apparaît dans la console).
Voici l’avis de Fsphil (l’auteur de hackTV) sur le problème rencontré par Clopos, il indique que l’utilisation du SECAM L avec de l’audio entraîne une plus grande utilisation du CPU :
Dès que tu vois la mention « UUUU » s’agrandir dans la console lorsque le problème apparait sur le TV alors on peut suspecter un CPU qui ne tourne pas assez vite pour hacktv en mode SECAM-L avec audio nicam, ça passe en PAL parce qu’il y a moins de traitements à faire pour l’image et l’audio en terme de modulation par rapport à du SECAM L, mais ce n’est qu’une hypothèse, il faut la vérifier en testant avec un PC fixe équipé d’un CPU un peu plus puissant.
On peut essayer de contourner le problème en abaissant le taux d’échantillonnage (sample rate) via l’option -s de hacktv, ça peut faciliter le travail du CPU en mode SECAM-L, par défaut hacktv utilise un taux d’échantillonnage de 16 Mhz.
-s, --samplerate <value> Set the sample rate in Hz. Default: 16MHz
Le problème n’apparaît pas avec un périphérique USB vers VGA (FL2K) car l’audio n’est pas géré, donc moins de travail à faire pour le CPU.
Pour info j’ai fait des tests sur un PC fixe mais dont le CPU est ancien (un intel core 2 quad Q9650 3 Ghz de 2008), avec une carte tuner winfast DTV1800H l’image est stable en SECAM L mais la qualité du son est très moyenne (à peine audible), alors qu’en PAL B/G avec audio le son est meilleur.
Merci pour ces infos. Cela se confirme. Quand je paramètre l’échantillonnage à 12MHz au lieu des 16MHz par défaut, le problème de désynchro disparaît en modulation norme L + couleur Sécam.
Cela semble effectivement une limite de calcul.
Pa rapport aux fichiers (avec nonicam) qui fonctionnent bien et dont le son est à 16MHz, la différence pour ceux que je suis contraint de passer en 12MHz (y compris ton fichier test), la qualité s’en ressent bien sûr.
Je peux me contenter de ces « contournement ». Il reste bien sûr à traiter le Sécam car j’observe toujours les visages des personnages en vert… Comme si c’était du NSTC mal phasé.
En tout cas, tous ces essais permettront de guider ceux qui comme moi veulent utiliser le Hack RF One avec un Raspberry Pi 4…
tu peux aussi essayer de mettre à jour la version de hacktv utilisée dans ton raspberry pi 4, celle que j’avais installé à l’époque sur ton raspberry pi n’avait pas encore un correctif secam pour le mode modulé L (elle était présente que pour la version « SECAM composite » pour l’adaptateur FL2K), du coup les couleurs sont fausses en mode « SECAM L » (sauf pour le mode « SECAM composite »),
depuis Fsphil a corrigé aussi la version pour le SECAM L, les couleurs seront bonnes (mais avec toujours un retard de la chroma sur la luma) : github.com/fsphil/hacktv/commit … adc593852b
pour mettre à jour hacktv il faut aller dans le répertoire de compilation de hacktv, de mémoire je l’avais mis dans /home/pi/compilation/hacktv, une fois dans ce répertoire tu tapes la commande pour mettre à jour le code source de hacktv, puis « make », puis « sudo make install »,
cd /home/pi/compilation/hacktv
git pull
make
sudo make install
si le chemin n’existe plus ou si git refuse de mettre à jour le code source alors tu peux recloner le dépôt git dans un nouveau répertoire, recompiler et installer hacktv, pour cela tu tapes dans une console ces commandes :
cd /home/pi
mkdir new_compilation
cd new_compilation
git clone https://github.com/fsphil/hacktv.git
cd hacktv
make
sudo make install
Pour la fréquence d’échantillonnage regarde si le SECAM L est meilleur en passant à 13.8 ou 14 Mhz au lieu de 12 Mhz.
Hello,
Merci, j’ai mis à jour la version et le Sécam est bien plus « naturel ».
Au dessus de 12MHz, cela ne fonctionne pas bien. J’ai essayé plein de valeurs. C’est un compromis.
Par ailleurs, j’ai noté qu’en composite 819L (avec le FL2000), la conversion de résolution était variable. Pour certaines vidéo, j’obtiens presque la résolution d’époque. Je reste bluffé par la qualité d’image obtenue.
Il me reste plus qu’à trouver le moyen d’installer ma petite interface raspberry TV Hat et voir si je parviens à convertir et diffuser le flux à la volée en 819L (mais c’est peu probable en raison des limites observées sur l’audio… Ou alors en B/G PAL, seulement, peut-être).
Tout cela est quand même extrêmement intéressant !
Pour le tuner TNT si un seul raspberry pi ne suffit pas alors tu peux peut-être le mettre sur un second raspberry pi dédié au streaming (une version low cost avec 1 ou 2 Go de ram), ce raspberry aura le hat TNT, et diffusera sur le réseau (RJ45, wifi) les flux TNT, qu’un second raspberry pi (dédié au hacktv) récuperera via le réseau, ça permettra de bien répartir les tâches, les ressources.
Mais peut-être qu’un seul raspberry pi suffira, car hacktv n’utilise qu’un seul coeur CPU, et le raspberry pi 4 en a 4.
D’après Fsphill on peut en théorie améliorer les performances d’un raspberry pi 4 en compilant hacktv avec des options adaptées au CPU ARM :
there are some compile flags to use on the Pi4 that may improve things
-mcpu=cortex-a72 -mfloat-abi=hard -mfpu=neon-fp-armv8 -mneon-for-64bits
Autre piste : utiliser un système de refroidissement (passif ou actif) pour le CPU, afin d’éviter que la fréquence du CPU soit réduite par le système, une température CPU qui reste dans des limites raisonnables autorisera une fréquence de fonctionnement maximale.
Hello,
En fait, j’ai installé le Armor Case (sans ventilateur) mais en ajoutant le précédent ventilateur.
Avant j’obtenais de 46 à 54°C selon l’activité. Désormais, je suis entre 37° au mini et 50° au maximum de sollicitation. Je ne note strictement aucun changement avec le refroidissement.
L’idée de recompiler pour le ARM pourrait être efficace mais la compilation, je n’ai jamais fait ça, ne maîtrisant pas du tout Linux.
Pour la récupération d’un flux en direct, je me demande si ma Freebox ne me permettrait pas de récupérer un TS de chaîne TV par mon réseau IP local (le NAS de la Freebox V6) pour ensuite le traiter avec HackTV.
J’ai enfin une image stable en 625 et 819 lignes quelque soit la norme d’émission.
J’ai réduit le sample rate à 8MHz au lieu de 16, l’image a perdu en finesse mais c’est stable, les autres fréquences ne donnent que des décrochages.
La suppression du nicam, de la couleur et du son, ne changeait rien à mes sautes d’images.
Seul le sample rate règle mon problème, en attendant d’avoir un autre pc plus puissant.
J’avais testé mon port usb avec la commande linux et j’avais 38Mib/s ce qui est normale mais je pense que mon cpu de 2008 est un peu juste pour ça.
Je vais faire un essai au lycée sur un pc dernière génération, ça ira surement mieux.
Autre chose, je souhaite faire de l’émission AM en bande radio PO et aussi un peu de FM pour tester, est ce qu’il y a une appli aussi « simple » que Hacktv pour faire ça?
Et une autre chose, comment peut on faire du DAB ou du DVBT avec notre hackrf?
Pour ceux qui travaille sur le 441 lignes, les lignes de codes que j’ai donné ne fonctionne pas, ça plante le programme, obligé de remettre le fichier d’origine (heureusement que j’ai fait une copie de celui-ci.
Pour de l’émission radio je n’ai trouvé que gnu-radio, où le concept est d’assembler des briques de fonctions avec la souris pour créer un graph, comme un légo, afin de réaliser précisément ce que l’on souhaite en terme de SDR, chaque brique pouvant être paramétrable et ayant une fonction précise :
ici un exemple de recepteur FM complet sous forme de graph :
pour de l’émission FM en mono (graphique simple, il y en a des plus compliqués donnant une meilleure qualité audio) :
D’autres graphs sont possibles pour émettre en DVB-T, DAB+, wifi, bluetooth, 4G avec gnu-radio, il faut regarder les tutoriels,
la gamme de fréquences du hackRF va de 1 Mhz à 6 Ghz, si on veut qu’écouter la radio analogique en balayant les fréquences alors il y a le logiciel gqrx : framalibre.org/content/gqrx-sdr
Bravo pour les avancements et expérimentations.
Émettre aux fréquences inférieures à 10 MHz n’est pas vraiment possible avec le HackRF One, il existe peut-être des convertisseurs et filtres externes mais je l’ignore.
Si pour la réception c’est assez simple de trouver des solutions, la modulation dans les OM doit être plus complexe, surtout pour les étages HF et les antennes en raison de la puissance nécessaire.
À partir de 10.000 kHz (10 MHz), les ondes moyennes, le HackRF est normalement capable de moduler, selon les utilisateurs.
Doctsf (Modèles & Marques)
Annonces
