Bienvenue sur SJCAM France
Les tests : SJCAM SJ6 Legend - Xiaomi Yi II - MELIFE Inspiration-i3 - SJCAM M20 - EKEN H9 - EKEN H8R - ELEPHONE Explorer Pro - AMKOV AMK100S 360° - SOOCOO CUBE 360°
Test en cours : SJCAM SJ7 Star
Envie de trouver la belle affaire ? Découvrez notre compilation des meilleures offres (et surveillez les ventes flash) !

Tutoriel Hacks (enfin, modif) Firmware SJ5000+
#1
Grand sourire 
Salut,

Evoqué dans ce sujet, je parlais des "hacks" possibles des firmwares des caméras bâties autour des chipsets Ambarella

Je ne sais pas si le sujet est porteur et je n'avais jamais fait que "tester" différents autoexec.ash (script qui s'exécute au démarrage) sur mes gopros pour "le fun" n'en ayant jamais eu un vrai usage et regardé comment utiliser AFT (Ambarella Firmware Toolbox) pour changer le bitrate selon les modes vidéo....

Mais bon, j'avais envie d'être joueur et de reprendre un peu les bidouilles suite au dit sujet....

Donc je commence par :

Hack#1 : Changer (personnaliser) les images de sa caméra (ce qui en soit ne sert à rien je l'admets) :




Mode opératoire : je l'ai détaillé sur mon blog mais voilà les différentes étapes :
  • A l’aide d’AFT, ouvrir le firmware d’origine (Load A7 Firmware)
  • Extraire les partitions (Partitions => Extract All) et le contenu ROM sur disque (ROM/RFS => Extract ROM to disk) :
    Deux (sous) dossiers se créent : partitions et rtosfs
  • Modifier les fichiers concernés (logo_1st.jpg; logo_2nd.jpg, power_off.jpg) dans rtosfs.
    Pour conserver les données exif et les caractéristiques il est fortement conseillé de modifier les fichiers d’origine vs en créer de nouveau ! Dans tous les cas, respecter à minima le format JPG et la taille 640×480
  • Recomplier le firmware avec les fichiers modifiés (ROM/RFS => Build ROM from disk puis Build => Firmware update). Un message incitant à la donation (méritée) apparaît et le nouveau firmware est créé. Il se trouve au même niveau que celui source et se nomme « a7firmware.bin »
  • Afin de valider le dit firmware, il est conseiller de répéter l’opération d’ouverture et d’extraction. Si tout se passe bien, on peut le considérer comme valide.
  • Procéder à la mise à jour avec le dit firmware (renommé en SJCAM_FWUPDATE_V3.bin dans mon cas).

En cas de doutes, je vous recommande l'excellent article sur les firmwares du président ICI qui vous renverra le cas échéant vers la procédure.... de débrickage !
[+] Flashé 1x pour ce message...
#2
Sert à rien, mais classe quand même ! Star
#3
Hello Président.

On peut imaginer mettre ses coordonnées en cas de perte (et les 1% de chances de tomber sur une personne honnête)... même si on peut simplement aussi mettre ses coordonnées dans un fichier txt sur la carte.

J'admets, le sujet m'amuse.. ça faisait longtemps que je n'avais plus joué avec ça....
#4
Je confirme c'est vraiment pour le fun Sourire sinon pas bete l'idée de l'adresse au démarrage, en plus si le mec garde la caméra perdu il se tapera ton adresse à chaque démarrage lol
[+] Flashé 1x pour ce message...
#5
Pas mal la consolation... je devrais envisager une image :

pour développer la culpabilité de celui qui la trouverait sans la rendre Sourire

S'il y a de la "demande" le prochain tuto sera sur les modifs de bitrate.... même si c'est largement documenté sur le web... ex :




l'idée serait de creuser la table de correspondance des modes vidéos là dedans :


Le coup de modifier les langues et les intitulés ne me passionne pas.... :


Je vais peut être plus investir sur les scripts autoexec
[+] Flashé 1x pour ce message...
#6
Pour info, je me suis repenché sur le firmware et son édition en voulant me pencher sur la partie Bitrate...
J'ai même découvert les subtilités de l'AVR (VBR vs CBR je voyais bien)*....

Pour vous faire partager :
Le CBR (Constant BitRate) : le débit des données est constant au sein du fichier.
Le VBR (Variable BitRate) : le débit varie (augmente quand beaucoup de changement, baisse quand peu) en vue de maintenir une qualité théoriquement constante en optimisant la taille du fichier
L’ABR (Average BitRate) : l’encodeur se sert d’un débit moyen et tolère des variations pas trop importantes autour dudit débit (± x %). C’est le compromis entre le CBR et le VBR


En gros, le consensus est qu'à 24 Mbps / VBR en 1080p60fps pas la peine de toucher à ces valeurs... même si certains prétendent que 30 Mbps seraient "à peine suffisant" et 50 recommandés...
J'ai aimé les réponses pleine de bon sens qui disaient "peut être en théorie mais pratiquement, tant que je ne vois pas de macroblocs, je ne vois pas l'utilité de monter cette valeur"...

Ca tombe bien c'est ce que fait la SJ5000+ :


Sans compter qu'il faut que le hardware tienne le coup si les valeurs s'envolent un peu trop....

Je pense donc que cela va clore pour l'instant mes jeux sur le sujet, merci à @Skanif de m'avoir "relancé" dessus Sourire
[+] Flashé 1x pour ce message...
#7
PS : .... mais en regardant le soft qui permet de reflasher les Eken brickées : FRM (Firmware and Ressource Manager) et le répertoire A\RO_RES\UI\JPG fournis dans les sources... je me dis que je vais me pencher sur les caméras construites autour du Sunplus 6330M Sourire
#8
Hello,

Après échange avec le président, nous avons convenu que l'intérêt était des plus limité... vu qu'il n'y avait pas d'améliorations fonctionnelles (cf mon post ci-dessus sur les débits).

En plus c'est fourni sans garantie mais, si vous avez une SJ 5000+ type B4 et que vous voulez un firmware customisé aux couleurs du forum (oui ça restreint vraiment), le fichier est

Vous aurez ces deux images à l'accueil :



et celle-ci à la fermeture....


=> si je trouve un mod utile, genre "ajouter ou modifier un mode" (ex : 1080p@120fps) ou autre j'actualiserai sinon cela clos le sujet pour moi, sauf questions....
#9
Sinon pas possible justement de virer l'ecran d'accueil pour avoir un allumage plus rapide ?
#10
je ne sais pas.... peut être en "supprimant" les dites images avant la compilation mais j'ai peur que le "file not find" provoque qquechose de pire....

sinon (parce que j'ai menti et que je continue à plancher dessus), voilà les débits max recommandés par Chipset :

A2 - 16-20Mbit
A5 - 18-24Mbit
A7 - 24-32Mbit

A+
#11
(03/10/2016, 18:07)marsu66 a écrit : En gros, le consensus est qu'à 24 Mbps / VBR en 1080p60fps pas la peine de toucher à ces valeurs... même si certains prétendent que 30 Mbps seraient "à peine suffisant" et 50 recommandés...
J'ai aimé les réponses pleine de bon sens qui disaient "peut être en théorie mais pratiquement, tant que je ne vois pas de macroblocs, je ne vois pas l'utilité de monter cette valeur"...

Cela n'intervient pas que sur les macroblocs mais aussi sur les petits détails en commençant par une perte de contraste par rapport au reste de la scéne puis par leur disparition.

Sur une scène très chargée de détails en mouvement en 1080@60, on voit une amélioration de l'image jusqu'à au moins 60Mbps. ; je ne sais pas pour au-delà puisque je n'ai pas testé et cela a par exemple un impact important sur Youtube quand bien même la vidéo est réencodée à 7,5Mbps.

Comme là on parle de la source issue de la caméra, il faut que ce soit quasi parfait pour pouvoir ensuite être édité et encodé avec une qualité satisfaisante.

Sur la Git2 je suis en moyenne à 36,4Mbps pour du 1080@60 en VBR avec du max à 37,4 d'après BitrateViewer ; Donc c'est pratiquement du CBR.

Regarder la scène de la fontaine sur ces exemples (pas en petit format ici dans le forum):

exemple d'un encodage sur Premiere en CBR à 30Mbs :




exemple d'un encodage sur Premiere en CBR à 60Mbs :




exemple d'un encodage sur Premiere en CBR à 8Mbs :


#12
Hello MyPov,

Je regarde ça demain au bureau avec "une vraie connexion"....
Ceci étant autant j'entends l'importance de ne pas diminuer la valeur de la source... augmenter les bitrates jusqu'à presque deux fois la valeur de la source, je comprends moins ?....
Vu que je n'ai pas visualisé tes vidéos, mais lu ce que tu constates.... comment l'expliquerais tu ??? le réencodage ayant une large bande n'a pas besoin d'altérer la source ? mais justement ta source avant réencodage "native" vs ta vidéo réencodée à 60 Mbps, ça donne quoi ? et si ma thérorie est bonne, 40 Mbps devraient t'offrir la même qualité de 60 et 80 ne devraient rien ajouter

(05/10/2016, 13:52)marsu66 a écrit : voilà les débits max recommandés par Chipset :
A7 - 24-32Mbit

(05/10/2016, 17:27)MyPOV a écrit : Sur la Git2 je suis en moyenne à 36,4Mbps pour du 1080@60 en VBR avec du max à 37,4 d'après BitrateViewer ; Donc c'est pratiquement du CBR.

Bon... je vais me préparer un p'tit firmware perso et filmer demain avant /après son application pour voir si je vois des différences notables entre 24 et 30 Mbps....

MyPov, pousse au crime Sourire complice
#13
(05/10/2016, 19:47)marsu66 a écrit : Ceci étant autant j'entends l'importance de ne pas diminuer la valeur de la source... augmenter les bitrates jusqu'à presque deux fois la valeur de la source, je comprends moins ?....
Vu que je n'ai pas visualisé tes vidéos, mais lu ce que tu constates.... comment l'expliquerais tu ??? le réencodage ayant une large bande n'a pas besoin d'altérer la source ? mais justement ta source avant réencodage "native" vs ta vidéo réencodée à 60 Mbps, ça donne quoi ? et si ma thérorie est bonne, 40 Mbps devraient t'offrir la même qualité de 60 et 80 ne devraient rien ajouter

Alors c'est subtil à expliquer, non pas en raison de tes capacités à comprendre mais des miennes à écrire ; Je vais tenter... Sourire

A chaque encodage il y a une perte de qualité, donc :

La scène A => donne la vidéo B brute via la cam ; B a une perte X de qualité par rapport à A (du fait d'utiliser en encodage avec perte, ici du H264 et ce quelque soit le bitrate)

La vidéo B brute => donne la vidéo C après édition; C a une perte Y de qualité par rapport à B (du fait d'utiliser en encodage avec perte, ici du H264 et ce quelque soit le bitrate)

Donc la perte finale de la vidéo C par rapport à la scène de la vraie vie A est X + Y.
Il faut bien que C soit le plus proche possible de la qualité de B et ce quelque soit la qualité avec laquelle B a été tournée, sinon on ajoute encore de la perte de qualité de C par rapport à A.

Est-ce compréhensible ? Sourire

Le choix de la qualité d'encodage de B n'a pas d'impact sur la choix de la qualité d'encodage de C.

Donc ma Git2 encode la vraie vie à 36Mbps avec une perte, mais après édition je veux être le plus proche possible de la vidéo encodée par la Git2, donc il faut parfois que je monte à 60Mbps (et même peut être plus)
[+] Flashé 1x pour ce message...
#14
Hum

Jusqu'à
(05/10/2016, 20:15)MyPOV a écrit : Donc la perte finale de la vidéo C par rapport à la scène de la vraie vie A est X + Y.
Il faut bien que C soit le plus proche possible de la qualité de B et ce quelque soit la qualité avec laquelle B a été tournée, sinon on ajoute encore de la perte de qualité de C par rapport à A.
Est-ce compréhensible ? Sourire
je suis plus qu'en phase et j'ai même tenu des propos similaires sur la perte liée aux encodages successifs relatifs à la vidéo "360"... donc plus que compréhensible Sourire complice

par contre là je "bloque" intellectuellement :

(05/10/2016, 20:15)MyPOV a écrit : Le choix de la qualité d'encodage de B n'a pas d'impact sur la choix de la qualité d'encodage de C.
Donc ma Git2 encode la vraie vie à 36Mbps avec une perte, mais après édition je veux être le plus proche possible de la vidéo encodée par la Git2, donc il faut parfois que je monte à 60Mbps (et même peut être plus)

Pour moi OUI il y a un impact entre la qualité de B et de C car le bitrate de C doit être supérieur ou égal à celui de B car je suis parfaitement OK sur le fait que le réencodage pour faire C va diminuer ta qualité en refaisant une passe de compression. Ca serait donc une abomination de descendre par rapport à la source B...

Mais appliquer presque un coef 2 sur le bitrate pour "compenser" (limiter) la compression est ce que tu trouves "pertinent" à la suite de tes essais ???
J'avoue que ça me parait énorme (je ne parle pas de la taille du fichier en sortie).
#15
(06/10/2016, 08:14)marsu66 a écrit : Mais appliquer presque un coef 2 sur le bitrate pour "compenser" (limiter) la compression est ce que tu trouves "pertinent" à la suite de tes essais ???
J'avoue que ça me parait énorme (je ne parle pas de la taille du fichier en sortie).

Et bien oui, c'est ce que j'ai visuellement constaté sur les scènes chargées filmées en 1080@60, sans ambiguïté il y a une différence de qualité entre du 30Mbps, 40Mbps et du 60Mbps.

J'ai presque envie de dire qu'il faudrait que les cams filment à 60Mbps car forcément on perd de la qualité sur certaines scènes.

Par contre ça pose un autre problème pour les cams : le poids des vidéos et de la puissance nécessaire de tout le hard car la vidéo ne peut pas être compressée en VBR 2 passes, puis ensuite ça engendre un coût aussi au niveau de montage pour travailler de telles vidéos.

60Mbs pendant 5 minutes : 60 x 60 x 5 / 8 = 2,25 Go

Je suis curieux de connaitre le débit des caméras professionnelles de cinéma ou de la TV.


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)