Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 5 sur 30 PremièrePremière 1234567891011121315 ... DernièreDernière
Affichage des résultats 121 à 150 sur 875
  1. #121
    Citation Envoyé par newbie06 Voir le message
    Trop facile : soit OpenOffice, soit qemu
    Et dans les trucs utilisables pour de vrai dans une entreprise sérieuse à tendance non geeks, t'as quoi ?
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  2. #122
    Citation Envoyé par Neo_13 Voir le message
    Si mon client était prêt à passer sous linux, tu aurais changé la vie d'un service de pointe complet.

    Seulement... Ils sont prêt à passer à linux... mais pas à se passer d'excel. Or même avec wine, sur ARM...
    Il me semblais avoir lu justement des papiers sur des technos qui permettent ça ... si seulement j'avais gardé un lien :/

    Me semble qu'il y avait eu ces infos sur une dépêche LinuxFR à propos de nspluginwrapper ...

  3. #123
    Ouais, mais bon, le consultant, dans 3semaines, il plie les gaules et dégage. Donc pour enclencher ce genre de process complexe, que ce soit qemu, un wrapper ou etc... ce sera non.
    Même si je pense que mes milliers de lignes de macros doivent être à peu près portables vers openoffice.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  4. #124
    Dans une vraie entreprise on n'utilise pas Excel avec des milliers de lignes de macro. Et quand on est un vrai consultant, on le dit à l'entreprise et on se casse.

    Je te taquine, t'aimes ça cochonne

  5. #125
    Citation Envoyé par newbie06 Voir le message
    Dans une vraie entreprise on n'utilise pas Excel avec des milliers de lignes de macro. Et quand on est un vrai consultant, on le dit à l'entreprise et on se casse.

    Je te taquine, t'aimes ça cochonne
    Quand on est consultant on dit "Cela fonctionnerait beaucoup mieux avec une base SQL centralisée synchronisable avec les terminaux offline 80% du temps, quelques scripts python ou php et utilisé via un navigateur. Ca dégage tous problèmes de décohérence entre les versions, tout problème de plateforme (palm/iphone/... possible) et c'est nettement plus puissant dans l'analyse" Et après le "Excel serait mieux", on a eu l'honnêteté de dire comment résoudre le problème, le client de toute façon préfère que ça merde avec sa solution plutot que ça fonctionne avec la tienne.

    CONSULTING : quand on ne fait pas partie de la solution, il y a beaucoup d'argent à se faire à ne pas la trouver...

    C'est pas tout à fait :
    CONSULTING : art de faire pour cher un travail incorrect pour éviter au client chef de remettre en cause ses choix technologiques et ses certitudes personnelles.

    EDIT : sinon t'as un MP mon lapin.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  6. #126
    Excel ca marche tres bien ! J'en ai vu qui generaient du RTL a partir de macros word qui utilisaient des MAS bien template...

    Comme quoi, y'a toujours pire !
    fefe - Dillon Y'Bon

  7. #127
    Ouai et y'en a meme qui utilisent TCL pour faire des GUI et PERL pour faire du "parsing".

  8. #128
    Citation Envoyé par newbie06 Voir le message
    Dans une vraie entreprise on n'utilise pas Excel avec des milliers de lignes de macro. Et quand on est un vrai consultant, on le dit à l'entreprise et on se casse.

    Je te taquine, t'aimes ça cochonne
    Donc 99% des entreprises mondiales sont des fausses :D

  9. #129
    Ah, moi j'ai mieux :
    Pilotage de batchs sur serveurs Unix (sous Itanium tiens, la boucle est bouclée) depuis Excel, via PLink.

    Le topic ARM est en train de se transformer en topic sur solutions foireuses.
    Mais ne l'était il pas depuis le début ? :solidarité modératrice et consultanesque:

  10. #130
    Citation Envoyé par Yasko Voir le message
    Le topic ARM est en train de se transformer en topic sur solutions foireuses.
    Je te trouve sympa : tu aurais pu dire que ce topic a toujours porte sur des solutions foireuses

  11. #131
    Citation Envoyé par Yasko Voir le message
    Ah, moi j'ai mieux :
    Pilotage de batchs sur serveurs Unix (sous Itanium tiens, la boucle est bouclée) depuis Excel, via PLink.

    Le topic ARM est en train de se transformer en topic sur solutions foireuses.
    Mais ne l'était il pas depuis le début ? :solidarité modératrice et consultanesque:
    Wowm la c est balaize
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  12. #132
    Citation Envoyé par newbie06 Voir le message
    Je te trouve sympa : tu aurais pu dire que ce topic a toujours porte sur des solutions foireuses
    Je suis pas sympa, et à mon avis, le contraste de ton écran est trop faible...

  13. #133

  14. #134
    C'est triste de constater que même les modérateurs s'épanchent dans le hors-sujet :/

    Saylakrize ?

  15. #135
    Ca donne quoi les OMAP3 en encodage vidéo ?
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  16. #136
    Citation Envoyé par Neo_13 Voir le message
    Ca donne quoi les OMAP3 en encodage vidéo ?
    IVA™ 2+ (Image Video Audio) accelerator enables multi-standard (MPEG4, WMV9, RealVideo, H263, H264) encode/decode at D1 (720x480 pixels) 30 fps
    Mais je ne sais pas à quel point le soft est facile à avoir. Le problème est que les IP video ne sont pas documentées et que peut-être certains codecs sont payants.

  17. #137
    OK

    Vive le libre.

    En fait, le proprio payant ne me choque pas tellement, mais un CC BY NC ce serait mieux pour des softs pros.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  18. #138
    Question bête, ffmpeg ça passe pas là dessus ?

    Vu la soupe qu'est le code, ...

  19. #139
    Citation Envoyé par Lissyx Voir le message
    Question bête, ffmpeg ça passe pas là dessus ?

    Vu la soupe qu'est le code, ...
    Bien sûr que ça passe, c'est même le premier code libre optimisé NEON (le SSE ARM) à avoir été écrit sur OMAP3 Les perfs sont pas mal : 720p sur MPEG2, moins sur h.264 qui n'a pas encore été bien optimisé (je parle de décode là).

  20. #140
    Et y'a un vrai support officiel, ou c'est un hippie aux cheveux gras qui l'a fait dans son garage au lieu de passer un noël en famille ?

  21. #141
    Hard-Adv rassemble les plus gros trolls de CPC.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  22. #142
    Citation Envoyé par Lissyx Voir le message
    Et y'a un vrai support officiel, ou c'est un hippie aux cheveux gras qui l'a fait dans son garage au lieu de passer un noël en famille ?
    Code:
    $ svn log libavcodec/arm
    ------------------------------------------------------------------------
    r17679 | mru | 2009-03-01 13:11:02 +0100 (Sun, 01 Mar 2009) | 1 line
    
    ARM: fix missing MUL16() return type
    ------------------------------------------------------------------------
    r17657 | mru | 2009-02-28 14:48:54 +0100 (Sat, 28 Feb 2009) | 1 line
    
    ARM: fix corner-case overflow in H.264 weighted prediction
    ------------------------------------------------------------------------
    r16868 | mru | 2009-01-31 00:13:19 +0100 (Sat, 31 Jan 2009) | 1 line
    
    ARM: NEON optimised vector_fmul_window
    ------------------------------------------------------------------------
    r16867 | mru | 2009-01-31 00:13:15 +0100 (Sat, 31 Jan 2009) | 1 line
    
    ARM: NEON optimised vector_fmul
    ------------------------------------------------------------------------
    r16824 | mru | 2009-01-27 17:34:10 +0100 (Tue, 27 Jan 2009) | 1 line
    
    ARM: remove some unused macro arguments
    ------------------------------------------------------------------------
    r16823 | mru | 2009-01-27 17:06:51 +0100 (Tue, 27 Jan 2009) | 2 lines
    
    ARM: reorder some instructions in put_pixels*_arm for speed gains
    
    ------------------------------------------------------------------------
    r16822 | mru | 2009-01-27 17:06:47 +0100 (Tue, 27 Jan 2009) | 1 line
    
    ARM: replace jump tables with conditional branches
    ------------------------------------------------------------------------
    r16821 | mru | 2009-01-27 17:06:44 +0100 (Tue, 27 Jan 2009) | 1 line
    
    ARM: replace explicit literal loads with ldr Rd, =lit
    ------------------------------------------------------------------------
    r16820 | mru | 2009-01-27 17:06:41 +0100 (Tue, 27 Jan 2009) | 1 line
    
    ARM: change alignment of loops in put_pixels*_arm to 32
    ------------------------------------------------------------------------
    r16819 | mru | 2009-01-27 17:06:38 +0100 (Tue, 27 Jan 2009) | 1 line
    
    ARM: optimised mid_pred()
    ------------------------------------------------------------------------
    r16818 | mru | 2009-01-27 17:06:34 +0100 (Tue, 27 Jan 2009) | 1 line
    
    ARM: allow register operands for shifts in MULL()
    ------------------------------------------------------------------------
    r16771 | mru | 2009-01-25 14:04:45 +0100 (Sun, 25 Jan 2009) | 1 line
    
    ARM: NEON optimised H.264 weighted prediction
    ------------------------------------------------------------------------
    r16770 | mru | 2009-01-25 14:04:41 +0100 (Sun, 25 Jan 2009) | 1 line
    
    ARM: NEON optimised H.264 biweighted prediction
    ------------------------------------------------------------------------
    r16684 | diego | 2009-01-19 16:46:40 +0100 (Mon, 19 Jan 2009) | 2 lines
    
    cosmetics: Remove pointless period after copyright statement non-sentences.
    
    ------------------------------------------------------------------------
    r16677 | mru | 2009-01-18 21:43:11 +0100 (Sun, 18 Jan 2009) | 1 line
    
    ARM: simplify ff_put/avg_h264_chroma_mc4/8_neon definitions, no code change
    ------------------------------------------------------------------------
    r16600 | aurel | 2009-01-14 18:19:17 +0100 (Wed, 14 Jan 2009) | 3 lines
    
    replace all occurrence of ENABLE_ by the corresponding CONFIG_, HAVE_ or ARCH_
    and remove all ENABLE_ definitions.
    
    ------------------------------------------------------------------------
    r16590 | aurel | 2009-01-14 00:44:16 +0100 (Wed, 14 Jan 2009) | 3 lines
    
    Change semantic of CONFIG_*, HAVE_* and ARCH_*.
    They are now always defined to either 0 or 1.
    
    ------------------------------------------------------------------------
    r16570 | mru | 2009-01-12 21:37:49 +0100 (Mon, 12 Jan 2009) | 1 line
    
    ARM: use push/pop pseudo-instructions in simple_idct_armv6.S
    ------------------------------------------------------------------------
    r16569 | mru | 2009-01-12 21:37:39 +0100 (Mon, 12 Jan 2009) | 1 line
    
    ARM: simple_idct_armv6.S whitespace cosmetics
    ------------------------------------------------------------------------
    r16568 | mru | 2009-01-12 21:37:33 +0100 (Mon, 12 Jan 2009) | 1 line
    
    ARM: clean up pc-relative references in simple_idct_armv6.S
    ------------------------------------------------------------------------
    r16567 | mru | 2009-01-12 21:37:29 +0100 (Mon, 12 Jan 2009) | 1 line
    
    ARM: use rX register names in simple_idct_armv6.S
    ------------------------------------------------------------------------
    r16395 | mru | 2008-12-30 04:13:52 +0100 (Tue, 30 Dec 2008) | 1 line
    
    ARM: work around linker bug with movw/movt relocations in shared libs
    ------------------------------------------------------------------------
    r16392 | mru | 2008-12-30 04:13:40 +0100 (Tue, 30 Dec 2008) | 1 line
    
    ARM: rename coefficient table in NEON IDCT
    ------------------------------------------------------------------------
    r16352 | mru | 2008-12-26 20:52:52 +0100 (Fri, 26 Dec 2008) | 1 line
    
    ARM: NEON optimised float_to_int16
    ------------------------------------------------------------------------
    r16312 | mru | 2008-12-26 00:13:43 +0100 (Fri, 26 Dec 2008) | 1 line
    
    ARM: add new h264 idct functions
    ------------------------------------------------------------------------
    r16179 | mru | 2008-12-17 01:54:54 +0100 (Wed, 17 Dec 2008) | 1 line
    
    ARM: replace "armv4l" with "arm"
    ------------------------------------------------------------------------
    Mans (mru) n'a pas les cheveux gras, et si tu lui dis un truc pareil, je ne réponds pas de ton état après
    A priori une release de ffmpeg va se faire dans les jours qui viennent et ça sera dedans

    Citation Envoyé par Neo_13 Voir le message
    Hard-Adv rassemble les plus gros trolls de CPC.
    Mon détecteur à troll est défaillant. Je les prends souvent pour des benêts et je leur explique comme à des gamins attardés.
    Dernière modification par newbie06 ; 04/03/2009 à 00h17. Motif: Fusion automatique

  23. #143
    Citation Envoyé par Neo_13 Voir le message
    OK

    Vive le libre.

    En fait, le proprio payant ne me choque pas tellement, mais un CC BY NC ce serait mieux pour des softs pros.
    Je pense surtout que ces technos ont besoin de tellement d'optimisations fines, qu'il n'est pas possible d'avoir des équipes gigantesques qui travaillent dessus. Résultat, tu te retrouves à avoir des très petites équipes qui font des merveilles, et les grosses boitent qui avancent pas.

    Rajoute à ca l'IP sur les encodages/décodages qui ne sont pas accessibles aux petites structures, et ca devient le bazard : Décoder le h264 en toute logique demande une licence. Décoder le AC3 demande une licence. En bref, tu veux gagner des sous sur un décodeur ultra perf, c'est quasi mission impossible pour une petite structure (qui pourtant aurait un produit au top).

    Idem, pour les accès aux specs (Close To Metal, Cuda, Stream, OMAP3, Cell, ...), tu as besoin de payer des sommes pharamineuses ou alors avoir tout simplement porte close et donc impossible de faire du code spécifique pour un produit avec des optimisation bourrines possibles sur x86 (ou alors très difficilement)

    (Ceci est la vision que j'ai eu avec les difficultés rencontrés par l'équipe de CoreCodec, et qui finalement est assez révélatrice )

  24. #144
    Les specs du Cell sont disponibles, non ?

    Quant a la qualite de ce qui est fourni par les (gros) constructeurs, une petite histoire vraie. Je connais quelqu'un qui bosse dans une boite qui fabrique des set-top box. Ils utilisent un processeur specialise pour certains codecs ; ce processeur vient avec une librairie de codecs. Il a fallu qu'un hacker de cette boite de STB reverse-engineer cette librairie pour corriger les bugs que le constructeur mettait trop longtemps (voire ne parvenait pas) a corriger. (Et ca a pu se faire, parce que le hacker dont je parle est probablement le meilleur programmeur que je connaisse.)

  25. #145
    Citation Envoyé par newbie06 Voir le message
    Les specs du Cell sont disponibles, non ?

    Quant a la qualite de ce qui est fourni par les (gros) constructeurs, une petite histoire vraie. Je connais quelqu'un qui bosse dans une boite qui fabrique des set-top box. Ils utilisent un processeur specialise pour certains codecs ; ce processeur vient avec une librairie de codecs. Il a fallu qu'un hacker de cette boite de STB reverse-engineer cette librairie pour corriger les bugs que le constructeur mettait trop longtemps (voire ne parvenait pas) a corriger. (Et ca a pu se faire, parce que le hacker dont je parle est probablement le meilleur programmeur que je connaisse.)
    Les specs, oui, mais je suis pas certain que l'accès aux SPE/SPU soit possible pour n'importe qui. Il me semble (à confirmer hein) que tu as besoin d'acheter le SDK/Dev kit de Sony pour y avoir accès. Et que par défaut, tu n'as accès que au PPE/PowerPC.

    Celà dit, ton exemple est typique du milieu je pense :D (Sigma, mon amour ?)

  26. #146
    Citation Envoyé par Oxygen3 Voir le message
    Les specs, oui, mais je suis pas certain que l'accès aux SPE/SPU soit possible pour n'importe qui. Il me semble (à confirmer hein) que tu as besoin d'acheter le SDK/Dev kit de Sony pour y avoir accès. Et que par défaut, tu n'as accès que au PPE/PowerPC.
    C'est completement faux Tu mets Linux sur ta PS3, et tu joues avec tes SP[EU].

  27. #147
    Citation Envoyé par newbie06 Voir le message
    C'est completement faux Tu mets Linux sur ta PS3, et tu joues avec tes SP[EU].
    [Troll]
    Ben oui, mais il a pas dit qu'il voulait jouer, mais y avoir accès, c'est à dire travailler.
    Ceci pour dire qu'il ne peut donc utiliser Linux,puisqu'il ne s'agit pas de "jouer avec les SPs", mais de travailler.
    [/Troll]
    There are only 10 types of people in the world: Those who understand binary, and those who don't.

  28. #148
    Citation Envoyé par newbie06 Voir le message
    C'est completement faux Tu mets Linux sur ta PS3, et tu joues avec tes SP[EU].
    Ton Linux, il tourne avec les SPEU ?

  29. #149
    Citation Envoyé par Oxygen3 Voir le message
    Je pense surtout que ces technos ont besoin de tellement d'optimisations fines, qu'il n'est pas possible d'avoir des équipes gigantesques qui travaillent dessus. Résultat, tu te retrouves à avoir des très petites équipes qui font des merveilles, et les grosses boitent qui avancent pas.
    +1
    Même dans les boites de tailles moyennes et les grosses boites, les équipes codecs sont assez petites.

    Citation Envoyé par Oxygen3 Voir le message
    Rajoute à ca l'IP sur les encodages/décodages qui ne sont pas accessibles aux petites structures, et ca devient le bazard : Décoder le h264 en toute logique demande une licence. Décoder le AC3 demande une licence. En bref, tu veux gagner des sous sur un décodeur ultra perf, c'est quasi mission impossible pour une petite structure (qui pourtant aurait un produit au top).

    Idem, pour les accès aux specs (Close To Metal, Cuda, Stream, OMAP3, Cell, ...), tu as besoin de payer des sommes pharamineuses ou alors avoir tout simplement porte close et donc impossible de faire du code spécifique pour un produit avec des optimisation bourrines possibles sur x86 (ou alors très difficilement)
    Il y a plein de boites qui font des codecs sans avoir de license mpeg-la ou Dolby. Il faut effectivement qu'à un moment donné la license soit payés, mais si tu vends des IP ou des librairies, ce n'est pas nécessairement toi qui doit payer les licenses liées aux codecs. Par contre, si tu fais des codecs ET que tu fais du B2C, alors oui, il faut bien supporter le cout de la license.

    Pour ce qui est des accès aux specs (genre Cell, OMAP, Cuda), je peux t'assurer que si tu es un acteur sérieux et que tu arrives assez tôt, tu ne payeras rien. TI, nVidia et les autres ont besoin de showcases pour vendre leurs produits. Il n'ont donc pas interêt à géner ceux qui réaliseraient ces showcases.
    Dernière modification par Gabriel ; 04/03/2009 à 14h40. Motif: grammaire

  30. #150
    Citation Envoyé par Oxygen3 Voir le message
    Ton Linux, il tourne avec les SPEU ?
    Tu vas finir par terminer dans ma boite troll toi
    J'ai fait un peu de programmation de SPU donc oui c'est accessible.

Page 5 sur 30 PremièrePremière 1234567891011121315 ... DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •