Non car cela aurrai aucun intéret...NEXUS6 a écrit :je n'interviens jamais dans ce topic ...
sauf ce soir
la prochaine version du rippack (s'il y en a une) ne devrait-elle pas être développée en .net ?
Futur rippack !
Modérateur : Modérateurs
- doctorf
- Expert
- Messages : 128
- Inscription : dim. oct. 19, 2003 9:46 pm
- Localisation : Grenoble --> Silicon french valley
- Contact :
Oui mais est ce vraiment utile et en quoi ??? ( en d'autre terme, c'est pas parcqu'il y a un effet de mode, utile pour certaines choses que tout doit être fait comme cela ) )...pourtant, il me semble que bcp de choses s'orientent vers le .net (Delphi 8 par exemple)
Dc-F
Il y a deux choses infinis, l'univers et la bétise humaine. Quoi que, pour l'univers, je ne suis pas sur. Albert Einstein.
Doctor F site : http://darksideeffect.free.fr
Doctor F site : http://darksideeffect.free.fr
- bruce
- Superviseur
- Messages : 1410
- Inscription : mer. avr. 18, 2001 2:00 am
- Localisation : In da beat we trust !
- Contact :
Honettement je ne vois pas trop l'intéret... Tous les softs qui ont tenté l'expérience du .net ont fait marche arrière pour le moment... Overnet (edonkey) était sorti en .net au début puis est revenu en version "normale".NEXUS6 a écrit :pourtant, il me semble que bcp de choses s'orientent vers le .net (Delphi 8 par exemple) ...
Le fait de télécharger le framework très lourd est beaucoup trop limitatif pour un apport minime...
En fait je vais utiliser ce post pour étaler ma science. lol.bruce a écrit :Honettement je ne vois pas trop l'intéret... Tous les softs qui ont tenté l'expérience du .net ont fait marche arrière pour le moment... Overnet (edonkey) était sorti en .net au début puis est revenu en version "normale".NEXUS6 a écrit :pourtant, il me semble que bcp de choses s'orientent vers le .net (Delphi 8 par exemple) ...
Le fait de télécharger le framework très lourd est beaucoup trop limitatif pour un apport minime...
Petite correction de puriste on dit pas développer en .NET mais développer pour .NET (je dit ca sans critiquer personne). Parce que .NET est la plateforme qui fait tourner les softs programmés spécialement pour elle. Pour les newbies .NET est une technologie similaire a JAVA développé par Microsoft (sans doute à la suite des maintes et maintes procès qu'il ont eu avec SUN Microsystems.) même si .NET est similaire, il y a de grandes différences avec Java. Par exemple .NET est entièrement dans le domaine public (autrement dit pas de droit a payer pour développer une plateforme sur un autre système d'exploitation ou bien pour développer pour cette plateforme. D'ailleurs il existe déjà des plateforme pour Mac et Linux si je ne m'abuse). Les programmes développés pour .NET peuvent tourner sur n'importe quelle plateforme .NET donc un programme fait sur Windows tournera sous Mac OS et sous Linux.
Seul pbm : la technologie est encore très jeune et bien des librairies ne sont pas encore implémentées ce qui devrait changer avec longhorn puisqu'aux dernières nouvelles le bureau windows et un tas de composants sous Longhorn devraient être programmés pour .NET. Mais d'ici a 2005 (date de sortie officielle de Longhorn) il y a de l'eau qui va passer sous les ponts comme qui dirait.
Donc je serais de l'avis de Bruce sur ce coup la, développer pour .NET est encore prématuré même si la prog pourrait tenir compte d'une évolution future vers cette plateforme.
- bruce
- Superviseur
- Messages : 1410
- Inscription : mer. avr. 18, 2001 2:00 am
- Localisation : In da beat we trust !
- Contact :
Bha c'est surtout que le framework n'est pas installé par défaut dans un seul windows disponible sur le marché (donc imaginez les "anciennes" versions) et que tous le monde n'a pas une connexion haut débit pour chopper ce framework.wazabbe a écrit :En fait je vais utiliser ce post pour étaler ma science. lol.bruce a écrit :Honettement je ne vois pas trop l'intéret... Tous les softs qui ont tenté l'expérience du .net ont fait marche arrière pour le moment... Overnet (edonkey) était sorti en .net au début puis est revenu en version "normale".NEXUS6 a écrit :pourtant, il me semble que bcp de choses s'orientent vers le .net (Delphi 8 par exemple) ...
Le fait de télécharger le framework très lourd est beaucoup trop limitatif pour un apport minime...
Petite correction de puriste on dit pas développer en .NET mais développer pour .NET (je dit ca sans critiquer personne). Parce que .NET est la plateforme qui fait tourner les softs programmés spécialement pour elle. Pour les newbies .NET est une technologie similaire a JAVA développé par Microsoft (sans doute à la suite des maintes et maintes procès qu'il ont eu avec SUN Microsystems.) même si .NET est similaire, il y a de grandes différences avec Java. Par exemple .NET est entièrement dans le domaine public (autrement dit pas de droit a payer pour développer une plateforme sur un autre système d'exploitation ou bien pour développer pour cette plateforme. D'ailleurs il existe déjà des plateforme pour Mac et Linux si je ne m'abuse). Les programmes développés pour .NET peuvent tourner sur n'importe quelle plateforme .NET donc un programme fait sur Windows tournera sous Mac OS et sous Linux.
Seul pbm : la technologie est encore très jeune et bien des librairies ne sont pas encore implémentées ce qui devrait changer avec longhorn puisqu'aux dernières nouvelles le bureau windows et un tas de composants sous Longhorn devraient être programmés pour .NET. Mais d'ici a 2005 (date de sortie officielle de Longhorn) il y a de l'eau qui va passer sous les ponts comme qui dirait.
Donc je serais de l'avis de Bruce sur ce coup la, développer pour .NET est encore prématuré même si la prog pourrait tenir compte d'une évolution future vers cette plateforme.
De plus l'encodage DivX (ou consort) fait appel à des codecs et autres éléments intégrés au système windows. Oui le logiciel ".net" tournera ailleur (mac, linux, bsd...) mais ne pourra rien faire tel quel vu qu'il fodrai repenser tous les appels vers les éléments d'encodage...
Il n'y a pas AviSynth sur Linux, pas de Vdub non plus... Oui il y a des alternatives mais dans ce cas autant programmer un soft complet pour Linux ou Mac plutot que chercher à adapter un soft windows à coup de patch et modules...
Bon, pour mettre mon grain de sel...
Je vois que les petits jeunes en première année de fac apprennent à développer en java. Et quand ils font un stage en entreprise ou quand ils cherchent du boulot, ils sont immédiatement opérationnels en Java sur les grands systèmes (AIX, Sun-OS, etc) en même temps que chez eux sur Windows ME ou sur Linux.
Si on les verrouillait sur .net, ils apprendraient un truc beaucoup plus limité, et devraient réapprendre java...
Bon, désolé, on s'écarte du sujet principal qui est le Rippack.
Je vois que les petits jeunes en première année de fac apprennent à développer en java. Et quand ils font un stage en entreprise ou quand ils cherchent du boulot, ils sont immédiatement opérationnels en Java sur les grands systèmes (AIX, Sun-OS, etc) en même temps que chez eux sur Windows ME ou sur Linux.
Si on les verrouillait sur .net, ils apprendraient un truc beaucoup plus limité, et devraient réapprendre java...
Bon, désolé, on s'écarte du sujet principal qui est le Rippack.
calcul de debit sous vdub
bruce a écrit :................................................................................................merde. Là c impossible de faire pareil pour la vidéo, vus que le débit change déjà d'un film à l'autre...
...................................................
bonjour,
je n'utilise pas bcp rippack en ce moment, mais on me demande souvent de traiter des sequences video (assez enormes de qqs 800mo a plus de 1000mo). J'utilise majoritairement vdub pour le reencodage video et audio. Je me dois donc de calculer au plus juste pour le bon bitrate (2pass) en tenant compte du debit audio en mp3 (souvent 56kbps 24khz stereo). Je realise tout simplement un calcul : ((Taille en ko divise par dureefilm en seconde)multiplie par 8) moins debit final du mp3 en kbps. La taille finale rentre toujours sur un cd (ds ce cas de 700mo) avec une qualite optimisee (divx 5.1.1 pro, profils desactives). Mon calcul ne tient pas compte du taux compression divx. Je ne touche pas aux reglages specifiques a nan/vdub sbc/brc ni aux settings image ds codec.
Tu pourrais utiliser ce type de calcul pour le bitrate video mais il ne prend pas non plus en compte la nature photo du film: dynamique (bcp mouvt) ou palette etendue (tres coloree), ces deux variables ayant pour effet d'influer bcp sur rapport taille/qualite du film. Ex: Mission Impossible 2 a moins de 700mo affiche des images pixellisees sur les frames d'explosion et de mouvements rapides.
Autre commentaire a propos du bitrate mp3: ds la version 16beta, il n'est pas possible d'utiliser un vbr 56kbps 24kbps stereo, le menu de choix se basant sur une onde wave de 44100hz et non pas de 48000hz ce qu'on obtiendrait naturellement avec ac3dec. Si je choisis un tel vbr, je me vois oblige de modifier l'echantillonage de l'onde (de 44.1khz a 48khz) avec le risque non negligeable de devoir qqfois reajuster la tempo sonore sous peine d'obtenir un decalage video/audio apres multiplexage.
Je sais que ton progr partait au debut pour simplifier le divixage (notamment pour les neophytes), mais je serais vraiment agreablement touche si tu pouvais integrer ce genre de manip ds une section pro de la nouvelle version (bien avant les nouv. opt que tu as proposes).
Je te salue, et je vais me coucher....
Les infos du forum sont tres interessantes. Tous sujets confondus, je lirai la suite demain soir, euh matin...
J.
- bruce
- Superviseur
- Messages : 1410
- Inscription : mer. avr. 18, 2001 2:00 am
- Localisation : In da beat we trust !
- Contact :
Re: calcul de debit sous vdub
Le son d'origine des DVD est en 48 Khz... Ensuite le rippack ne propose pas de VBR en MP3.theseeker a écrit :Autre commentaire a propos du bitrate mp3: ds la version 16beta, il n'est pas possible d'utiliser un vbr 56kbps 24kbps stereo, le menu de choix se basant sur une onde wave de 44100hz et non pas de 48000hz ce qu'on obtiendrait naturellement avec ac3dec. Si je choisis un tel vbr, je me vois oblige de modifier l'echantillonage de l'onde (de 44.1khz a 48khz) avec le risque non negligeable de devoir qqfois reajuster la tempo sonore sous peine d'obtenir un decalage video/audio apres multiplexage.
- pwaloku
- Empereur
- Messages : 5261
- Inscription : ven. août 02, 2002 7:12 pm
- Localisation : Out of Belgium
Bien sûr, je peux comprendre qu'on ait espéré et qu'on soit déçu, mais il y a la façon de le dire. Et je maintiens qu'étant donné que Bruce a fait son soft gratuitement, il ne doit rien à personne...
"L'absence totale d'humour dans la bible est une des choses les plus étranges de la littérature." (A. N. Whitehead).