Forum m4ng - medi4 next gen

tin ça fait 1/2h que je cherchais pourquoi rien ne fonctionnait, et j'avais bridé l'analyse de la durée de la vidéo, forcément ça marchait moins bien

kelkon ce pepsi...

bon, je ne capte rien aux résulats, matou, j'ai besoin de toi, que dois-je faire une fois la vidéo "quantizée" créée et que j'ai récupéré sa taille? je ne comprends plus rien aux formules vieilles de 6 ans

instaurées dans ripp-it et m4ng par la suite.

@Laulau, surement très bien ton pavé, mais pas très concis pour mon modeste cerveau pas matheux pour un sou

voilà ce que m4ng fait :

1. ratio = 100/pourcentage du test
2. testsize = taille_vidéo_réencodée_pour_test*ratio (pour passer la taille "portion" en taille "entière")
3. encodesize = taille_vidéo_demandée_suivant_débit
4. indice=calcul de l'indice de qualité : (débit/fps)/(resx*resy)
5. résultat du test = testsize/encodesize
6. taux de compression = indice / résultat du test.

Les chiffres obtenus ne ressemblent à rien de cohérent pour 5 et 6..

Perso j'aurais fais le calcul avec les débits mais en utilisant ta méthode je vois un truc bizarre :
1. ratio = 100/pourcentage du test --> ratio = pourcentage du test non ? parce que si tu testes sur 5% des frames c'est aussi 5% de la durée ...

Après le reste semble logique, sauf p-e la 6 que je comprends pas trop faudrait que je réfléchisse à ce que ça représente ...

Underground78 a écrit :Perso j'aurais fais le calcul avec les débits

Ouais, ce serait plus logique, c'est vrai...

mais en utilisant ta méthode je vois un truc bizarre :
1. ratio = 100/pourcentage du test --> ratio = pourcentage du test non ? parce que si tu testes sur 5% des frames c'est aussi 5% de la durée ...

Ben ouais, mais il faut bien extrapoler la taille entière de la vidéo de test pour la comparer à la taille estimée de la vidéo réencodée, donc je multiplie la taille de 5% par 100/5, soit 20, 20x5 = 100%

Après le reste semble logique, sauf p-e la 6 que je comprends pas trop faudrait que je réfléchisse à ce que ça représente ...

En fait les résultats ne sont pas si incohérents que ça, j'avais poussé le débit trop haut, pour que le résultat soit bon, il faut mettre 4000 kbps... Par contre, envoyer un débit de 4000 kbps au codec, facile, envoyer pour chacun un quantizer, galère à prévoir

Ah oui c'est moi qui déconne mais le plus simple ça serait prendre les débits. Par contre moi j'aurais fait debitchoisi / debitobtenu mais toi avec la taille tu as l'inverse.

Je ne vois pas trop le problème avec les quantizer ? Tu codes en dur un Q2 pour Divx/Xvid, Q?? pour le x264, etc, etc ...

Underground78 a écrit :Ah oui c'est moi qui déconne mais le plus simple ça serait prendre les débits. Par contre moi j'aurais fait debitchoisi / debitobtenu mais toi avec la taille tu as l'inverse.

Ouais, mais je ne vois pas trop comment me servir des débits à la place de la taille dans mes calculs à la noix... En fait j'ai trouvé pourquoi les résultats ne me semblaient pas cohérents, en fait quelque soit le débit vidéo demandé, le résultat était toujours comparé à la même taille finale mal calculée donc tout était faux, là j'ai changé le calcul de taille en faisant débit * durée et les résultats sont normaux, mais celà dit, je constate aussi que le test ne sert pas à grand chose, pour avoir un taux de 50%, il faut un indice de qualité de 0.10, ce qui est plus ou moins la norme à appliquer pour tous les encodages....

Je ne vois pas trop le problème avec les quantizer ? Tu codes en dur un Q2 pour Divx/Xvid, Q?? pour le x264, etc, etc ...

Je te rappelle pour mémoire qu'il y a 74 appels de x264.exe dans m4ng selon le cas de figure, des appels "génériques" tels quels et ce serait les mêmes à utiliser pour le test de compressibilité selon le cas, je ne vais pas me lancer à changer ça "en dur" comme tu dis, c'est un coup à avoir des bugs pour les 10 ans à venir... Enfin, quoiqu'il en soit, je vais regarder dans le code d'encodage ce que je peux faire

je viens de regarder :
1. pour le divx, il faut passer une ligne de commande à rallonge, "-bv1 debit ++ reste de la ligne", j'ignore totalement comment passer un quantizer
2. pour le xvid, c'est déjà plus intelligent, c'est par BDR interposée, la clef "bitrate" pour la valeur du débit vidéo, idem pour que le divx, comment on passe un quantize?
3. pour le MPEG via QuEnc, c'est pas prévu
4. pour le x264, je vais ptête attendre de voir ton module "externe" non?

Alors :
1) -bv1q #
2) à priori il y a une clé "mode" à mettre à 0, une clé "use_2pass_bitrate" à mettre à 0 et sinon une clé "desired_quant" à mettre à quantizer*10
3) -b # avec # < 32 sera considéré comme un quantizer
4) Ça se défend sinon la solution c'est prendre la ligne de commande de la passe 1, remplacer --pass 1 par --crf # et supprimer "--vbv-bufsize <#> --vbv-maxrate <#>".

Underground78 a écrit :Alors :
1) -bv1q #

-bv1q 2 donc?

2) à priori il y a une clé "mode" à mettre à 0, une clé "use_2pass_bitrate" à mettre à 0 et sinon une clé "desired_quant" à mettre à quantizer*10

quantizer*10?

3) -b # avec # < 32 sera considéré comme un quantizer

ah, ok...

4) Ça se défend sinon la solution c'est prendre la ligne de commande de la passe 1, remplacer --pass 1 par --crf # et supprimer "--vbv-bufsize <#> --vbv-maxrate <#>".

ouais ouais, je vais attendre

1) Oui

2) Oui, donc 20 pour 2, comme ça tu peux avoir des réels.

Bonjour,

Je confirme juste qu'il faut bien passer par un quantizer car j'ai fait quelques tests, et mettre un débit "énorme" (du moins pour du xvid) revient, à quelques kbits près, à mettre un Q=1, donc gros gâchis car il est universellement admis que la qualité max, c'est Q=2.

D'autre part, je crois que j'ai trouvé un bug mineur (peut-être déjà connu, j'avoue que je n'ai pas pris le temps de rechercher) : lorsque je modifie le délai audio, dans la fenêtre de prévisualisation, cette valeur n'est pas enregistrée dans le fichier batch, car quand je le recharge, c'est la valeur initiale qui réapparait.

En tout cas s'il y a besoin de faire un quelconque test, aucun problème !

Asterix a écrit :Bonjour,

Je confirme juste qu'il faut bien passer par un quantizer car j'ai fait quelques tests, et mettre un débit "énorme" (du moins pour du xvid) revient, à quelques kbits près, à mettre un Q=1, donc gros gâchis car il est universellement admis que la qualité max, c'est Q=2.

Perso les tests que j'ai faits n'étaient pas concluants, seul un gros débit donne un résultat cohérent...

D'autre part, je crois que j'ai trouvé un bug mineur (peut-être déjà connu, j'avoue que je n'ai pas pris le temps de rechercher) : lorsque je modifie le délai audio, dans la fenêtre de prévisualisation, cette valeur n'est pas enregistrée dans le fichier batch, car quand je le recharge, c'est la valeur initiale qui réapparait.

Ah, embêtant ça, je vais regarder...

En tout cas s'il y a besoin de faire un quelconque test, aucun problème !

Pour le test de compressibilité on n'en est pas là, tout est encore à l'état embryonnaire

Pour le test de compressibilité, ça n'a pour moi de sens qu'avec un quantizer ... J'essayerai de faire des tests.

pepsilite a écrit :
D'autre part, je crois que j'ai trouvé un bug mineur (peut-être déjà connu, j'avoue que je n'ai pas pris le temps de rechercher) : lorsque je modifie le délai audio, dans la fenêtre de prévisualisation, cette valeur n'est pas enregistrée dans le fichier batch, car quand je le recharge, c'est la valeur initiale qui réapparait.

Ah, embêtant ça, je vais regarder...

J'ai regardé, je n'ai rien vu d'anormal... J'ai chargé une vidéo, mis un delai de 1500, sauvé la tâche, fermé m4ng, réouvert la tâche, mon délai est toujours là ... j'ai raté quelque chose?

pepsilite a écrit :1. ratio = 100/pourcentage du test
2. testsize = taille_vidéo_réencodée_pour_test*ratio (pour passer la taille "portion" en taille "entière")
3. encodesize = taille_vidéo_demandée_suivant_débit
4. indice=calcul de l'indice de qualité : (débit/fps)/(resx*resy)
5. résultat du test = testsize/encodesize
6. taux de compression = indice / résultat du test.

J'ai testé un peu et je crois que ce qui cloche c'est le 5.

Moi j'ai fais à ma sauce :
1. résultat du test = débit désiré / débit du test
2. indice qualité = (débit désiré / fps) / (resx * resy)
3. taux de compression = %Q du texte de Lauden = indice qualité / résultat du test

et ça me donne des choses plutôt logique bien plus qu'en prenant "résultat du test = testsize/encodesize" soit en fait "résultat du test = débit du test / débit désiré" donc l'inverse de ce que j'ai pris ...

Après c'est assez étrange parce qu'en 3. tu peux simplifier en :
taux de compression = indice qualité / résultat du test = ((débit désiré / fps) / (resx * resy)) / (débit désiré / débit du test) = débit du test / fps * resx * resy = indice qualité avec le débit du test ...
Pour moi le %Q n'a aucun sens ...

comment tu connais le débit désiré en passant un quantizer?

pepsilite a écrit :comment tu connais le débit désiré en passant un quantizer?

Le "débit désiré" c'est celui qu'a entré l'utilisateur pour moi. Le "débit du test" c'est celui de la vidéo obtenue après le test de compressibilité.

ouais, débit du test, je voulais dire ... le débit entré par l'utilisateur? l'utilisateur n'entre pas de débit dans le test de comp... je n'ai peut-être jamais rien compris à ce test mais pour moi ça équivaut à mettre un débit "connu" et à voir ensuite la différence entre ce débit connu demandé (très grand, dans les 4000 kbps) et celui finalement obtenu dans la vidéo...

pepsilite a écrit :ouais, débit du test, je voulais dire ... le débit entré par l'utilisateur? l'utilisateur n'entre pas de débit dans le test de comp... je n'ai peut-être jamais rien compris à ce test mais pour moi ça équivaut à mettre un débit "connu" et à voir ensuite la différence entre ce débit connu demandé (très grand, dans les 4000 kbps) et celui finalement obtenu dans la vidéo...

Je pige pas ce que tu veux dire le débit désiré c'est celui pour le fichier final et le débit du test c'est le débit de la vidéo encodée avec le quantizer.

soyons clairs

"fichier final", c'est lequel pour toi?

Bah celui que l'utilisateur rentre dans m4ng directement ou qui est calculé à partir de la taille finale.

ah, donc je n'ai jamais rien compris à ce test, pas grave, je vais essayer de coder ce que tu préconises et on verra bien...

pepsilite a écrit :
pepsilite a écrit :
D'autre part, je crois que j'ai trouvé un bug mineur (peut-être déjà connu, j'avoue que je n'ai pas pris le temps de rechercher) : lorsque je modifie le délai audio, dans la fenêtre de prévisualisation, cette valeur n'est pas enregistrée dans le fichier batch, car quand je le recharge, c'est la valeur initiale qui réapparait.

Ah, embêtant ça, je vais regarder...

J'ai regardé, je n'ai rien vu d'anormal... J'ai chargé une vidéo, mis un delai de 1500, sauvé la tâche, fermé m4ng, réouvert la tâche, mon délai est toujours là ... j'ai raté quelque chose?

Vraiment ? Ça vient peut-être de mon DVD qui était comme qui dirait "custom made", l'analyse m'annonçait 4 pistes avec chacune 81499ms de délai, alors qu'il est en réalité de 2000ms (du moins pour la piste FR, j'ai pas essayé les autres).
Je dirais bien que je vais refaire des tests, mais j'ai justement supprimé mon dossier rippé ce WE après la réussite de l'encodage.

Je vais voir si je peux en récupérer des morceaux, mais j'ai peu d'espoir ...

peut-être que ça le fait quand il y a justement un délai à la base, j'ai testé sur une AVI qui n'en avait pas, je ferai le test avec un DVD qui en a un...

Ah oui, ou peut-être le fait qu'il y avait 4 pistes et que c'est la n°2 que je voulais "délayer"

Forum m4ng - medi4 next gen

Test de compressibilité