votre avatar

jb

est avec nous depuis le 13 mai 2006 ❤️

1157 commentaires

Le 13/03/2014 à 17h 28







Horrza a écrit :



Pourquoi VLC n’a pas les mêmes (?) possibilités que MPHC en matière d’amélioration d’image :http://www.ezoden.com/157/tutoriel-pc-home-cinema



C’est le jour et la nuit, dommage :(







Parce que la plupart, c’est du bullshit (ou déjà dans VLC) à part Reclock.



Et alors, vu la conf à faire, non merci: ça commence par:





Nous allons créer 2 répertoires pour avoir 2 installations de MPC-HC, une, par exemple, pour des écouteurs ou des haut parleurs stéréo (MPC-HC 2.0) et l’autre pour l’ampli en 5.1 (MPC-HC 5.1)


Le 13/03/2014 à 17h 23







night57200 a écrit :



Heum, est-ce que cette version gère le DLNA?



Les applications multimédia metro de ma tablette ne trouvent pas mon NAS DLNA et pour écouter de la musique je suis obligé de passer par WMP et le bureau, et ça me les broute légèrement, pour être honnête. Si VLC le gérait, ce serait énaurme <img data-src=" />







Oui, mais y a un bug. On va essayer de fixer rapidement.


Le 13/03/2014 à 16h 45







freechelmi a écrit :



Les ventes de tablettes W8 vont exploser ! <img data-src=" />







Je doute :)


Le 13/03/2014 à 16h 25







curuba a écrit :



Je comprend pas trop ce besoin de faire des applis pour du non-windows phone: on a déjà les .exe pour windows 8 “classique”



Quelqu’un pour éclairer ma lanterne ? :/





Parce que pour porter sous Windows Phone et Windows RT, tu dois passer par là.







zogG a écrit :



Toujours du mal avec ces interfaces en tuiles, pour la musique, pas de soucis, pour les vidéos ça n’a du sens que sur un XBMC like, là on a un aperçu qui ne donne aucune info, et plus la place pour afficher le titre du fichier en entier. <img data-src=" />







Et en quoi c’est différent pour un XBMC-like? En mode tablette, t’as juste pas vraiment le choix, t’as besoin d’un media-center like…







chaps a écrit :



Par contre je ne comprend pas pourquoi tant de personnes restent sous Windows 8 sans passer à Windows 8.1 <img data-src=" />. C’est gratuit pourtant !





Parce que c’est pas dans Windows Update, mais juste dans le store…


Le 07/03/2014 à 15h 42

Moi, c’est surtout hyper instable, ici… Surtout avec les pilotes AMD.

Le 28/02/2014 à 11h 47

Vu ce qui est pondu ici, je ne comprend pas le battage médiatique pour soutenir Castex, vis-à-vis du Parti Socialiste… Notamment de la part de l’April…

Le 27/02/2014 à 15h 04

Mise à jour du compilo, contrairement à l’update 1 :)

Le 07/02/2014 à 22h 27







digital-jedi a écrit :



500€ par mois, ça fait tout de même 6000€ à trouver dans l’année.





6000€ pour un logiciel qui a 60 millions d’utilisateurs, c’est faisable, tout de même…


Le 07/02/2014 à 15h 58







digital-jedi a écrit :



Donc il y a bien des besoins financiers sauf si vous avez une planche à billets. /D

Mais je ne vois pas de barre de donations avec un budget annuel à atteindre en face (comme PCI par exemple).







Euh, trouver 500€ par mois et plusieurs dizaines de milliers, c’est pas pareil…


Le 06/02/2014 à 10h 33







aurel_gogo a écrit :



@jb



Moi j’ai un bug avec VLC quand je regarde une vidéo et que je met la pause, en sortie de pause après quelques secondes de lecture la vidéo freeze, le son revient 5 secondes en arrière, j’ai quelques artefacts dégueux sur l’image et tous se resynchronise et marche correctement ensuite.



Ça le fait en sortie de pause et quand j’avance via la barre de progression.



Win8 64bits sur VLC en 32bits (Core i5 et Nvidia 520M)









Désactive l’accélération matériel…


Le 05/02/2014 à 12h 30







nost4r a écrit :



VLC qui plantait quand je lançais un jeu, c’était un bug connu ou c’était juste moi qui envoyer les rapports d’erreurs à chaque fois ?<img data-src=" />







C’est un bug avec les cartes nVidia…







digital-jedi a écrit :



Au fait, ils sont financés comment les gens de VideoLan ? On sait combien touche l’entreprise pour ce lecteur gratuit diffusé mondialement (si c’est suffisant ou pas ou astronomique) ?







Entreprise? Argent? Finance?



Tu déconnes ou bien???


Le 05/02/2014 à 11h 57







Elwyns a écrit :



oh passage, j’ai un petit soucis avec avec VLC et ma TV liaison HDMI résolution 1920x1080 60hz , quand je passe la fenêtre VLC sur la TV les séries / films sont légèrement saccadé à chaque image , ( synchro désactivé , decodage matériel désactivé, et la carte graphique ne force rien sur les lectures vidéos, processeur Phenom 965 ) ?



PS : j’ai essayé un tas de résolution et de fréquences, du coup je fini par passer sur le rpi / openelec



Version VLC vlc win 32 2.1.2







XP ? 7 ?


Le 05/02/2014 à 11h 14







Roukeuss a écrit :



J’en profite pour poser la question ici : VLC compte t-il supporter la clé ChromeCast suite à la mise à disposition du SDK ?







Euh, regarde le SDK…







benhuriet a écrit :



la version 64 bits reste bloquée en 2.1.2 ?





Non.







Mageti a écrit :



Des nouvelles du plugin VLSub qui ne marchait pas depuis VLC 2.1





2.2.0 :)







pako31 a écrit :



Cette màj était très attendue, j’avais du downgrader pour lire mes m2ts.



Merci à l’équipe <img data-src=" />





De rien.


Le 07/02/2014 à 12h 35







knos a écrit :



Et pendant ce temps là sur pc il ne lit toujours pas les Blu-ray <img data-src=" />



<img data-src=" />





<img data-src=" />


Le 07/02/2014 à 09h 21







kenshiro a écrit :



Et pendant ce tps là sur Android….. Mais bon ils sont réactif sur les autres plateforme







C’est vrai, on a juste, sous Android:





  • réécrit intégralement l’interface

  • bossé avec un designer

  • ajouté l’accélération graphique complète

  • réécrit le support des sous-titres

  • réécrit la sortie audio







    Bref, rien de bien…


Le 06/02/2014 à 16h 24







Vincent_H a écrit :



N’aie crainte, JB va venir râler <img data-src=" />





Grave!







zogG a écrit :



Vu que l’intérêt du 64 bits sur iOS et mobile plus généralement fait débat, et que jb est un membre actif de PCI, il serait intéressant de savoir ce que ça apporte (concrètement donc) dans le cas VLC. <img data-src=" />





C’est de la merde :)



Sinon, sous iOS, l’intérêt du 64bits, c’est principalement les sélecteurs Obj-C qui sont nettement plus rapide, et évidemment, plus de registres accédés.



Par contre, plus de ram utilisée…



Environ 10% de mieux en CPU que ARMv7s. Ensuite, on va ajouter plus de code ASM ARMv8…


Le 06/02/2014 à 11h 11

C’est open source, hein?

Le 03/02/2014 à 21h 48







®om a écrit :



Bien que techniquement intéressant, on peut regretter son manque d’ouverture et sa dépendance à Google.



En effet, en tant que développeur, il faut d’abord enregistrer son application auprès de Google pour obtenir un app id.



À chaque connexion, c’est Google qui fait le lien entre cet app id envoyé par l’application Android et l’url du receiver que doit récupérer le ChromeCast.



Et pour que ça marche côté client, il faut avoir les GooglePlayServices, avec l’acceptation de ses règles, à savoir, pour résumer “vous acceptez que Google fasse tout ce qu’il veut quand il veut sur votre ordinateur de poche”.



C’est dommage, car techniquement, rien n’obligeait cette sur-dépendance.





Ça fait plaisir d’avoir ce son de cloche et pas juste les commentaires élogieux comme on voit sur HN..


Le 30/01/2014 à 16h 59







dargos a écrit :



bon, ca a l’air d’etre limité à la documents library, mais il y a bien un quelque chose à creuser





Bah oui, mais c’est donc inutile. Si tu as un filepicker, c’est justement pour sortir des Library pré-définies. Donc, ça marche actuellement dans les libraries, mais pas à l’extérieur… :)


Le 30/01/2014 à 15h 17







Lafisk a écrit :



surtou qu’avec une app comme vlc, MS ecoutera alors qu’avec une app de coussin peteurs ils te renverront dans les choux





L’expérience montre qu ce n’est pas le cas.


Le 30/01/2014 à 15h 11







Lafisk a écrit :



Vu comment le systeme etait limite a la base, je rappelle qu’il n’y avait pas de copier coller, je suis casi sur que le framework aussi l’etait et je me rappelle avoir vu beaucoup de critiques sur les sockets aussi au depart.





Problème UI != Problème d’API de dev.







Lafisk a écrit :



Bien sur que tu ne change pas pour le plaisir, et bien sur win32 va pas disparaitre dans un an ou deux, apres, au devs de faire son choix,







En fait, ce que tu ne comprends pas, c’est que le souci n’est pas un souci de Win32 vs WinRT, mais de WinRT vs le reste du monde.



Les threads POSIX et Win32 sont assez proches, donc toutes les applications les utilisent. TOUTES, sur iOS, Android, Linux, BSD, Windows, XBox, PS1/2/3/4, lecteurs de salons, appliances et autres…



Même chose pour les sockets BSD. Même chose pour l’ouverture de fichier. Ou l’OpenGL.



Et toutes les librairies, de l’extraction de données au réseau, en passant par les calculs intensifs.



Les devs ne restent pas sur Win32, mais ont besoin d’une compatibilité avec les librairies importantes.

Et si t’es une plate-forme minoritaire et assez populaire, bah, tu imposes pas tes choix.


Le 30/01/2014 à 15h 00







yeagermach1 a écrit :



Pour le coup des fichiers par exemple, tu fais comment sur iOS. Dans mes souvenirs, il y a pas plus de fopen dans le sdk iOS que dans le sdk winRT ?







Tu peux ouvrir tous les fichiers dans ton jail. Et tu n’as aucun filesystem, contrairement à un desktop.


Le 30/01/2014 à 14h 56







dargos a écrit :



de là à dire que c’est de la merde et que c’est pour ca que les developpeurs vont sur telle ou telle plateforme, c’est un racourci que je ne ferais surement pas







Personne n’a dit que c’était de la merde, et certainement pas moi.



La question était pourquoi le portage était si compliqué, et la réponse a été donnée…


Le 30/01/2014 à 14h 51







Lafisk a écrit :



Oui et tout ca etait dispo tout de suite ? non, ya plein de chose que tu ne pouvais pas faire sur ios en terme de codage au depart …







Comme?



Le jour où il y a eu des applis sur iOS, toutes ces choses basiques mentionnées étaient là…


Le 30/01/2014 à 14h 48







dargos a écrit :



ca fait depuis 2008 qu’on utilise ce style de programmation.

alors si des devs ne se rendent compte qu’aujourd’hui qu’on fait du C#/XAML, je suis bien désolé pour eux…





Fait un codec et un demuxeur en C#, et on en reparle…



C’est atterrant un tel niveau de fanboyism…



Bon, j’arrête de commenter, ça ne sert à rien.

Mais ne vous étonnez pas que je n’ai aucune envie de porter VLC sur cet OS avec une communauté d’utilisateurs de ce niveau…



WinRT est la meilleure des plate-formes.


Le 30/01/2014 à 14h 48







dargos a écrit :



pour le coup du m3u, outre le partage, dans le manifest tu peux dire que ton appli est capable d’oubrir ce genre de fichier.





Je crois que tu n’as pas compris.



Une fois que tu as ouvert ton m3u, comment tu ouvres les fichiers qui sont pointés dans le m3u?







dargos a écrit :



ensuite pour pouvoir ouvrir des fichiers sans l’accord de l’utilisateur, je crois que dans le manifest toujours, tu peux elever les privileges, et ainsi avoir acces au file system tranquilement





Bien sûr que non.


Le 30/01/2014 à 14h 45







Lafisk a écrit :



Quand l’iphone est sorti ou android, les techniques de prog aussi etaient assez differente de ce a quoi etait habitue les devs jusque la et pourtant beaucoup s’y sont fait.





C’est totalement faux, coder sur iOS ressemble extrêmement fortement à Mac OS X.

Et ils ont threads, sockets et bindings Cocoa/C et les API audios sont identiques.


Le 30/01/2014 à 14h 21







yeagermach1 a écrit :



Je suis d’accord que c’est relou mais a part vouloir super ouvert (trop sans aucun doute) comme android, tu peux pas changer grand chose. C’est le comportement de base de winrt actuellement : bac a sable extrême pour tout.



Faut malheureusement s’y faire. Quoique cela va sans doute un peu s’améliorer avec les updates du SDK.







Oui, mais faut pas se plaindre du manque d’applis…


Le 30/01/2014 à 14h 10







yeagermach1 a écrit :



Pas faux, je voyais plus les clés USB et disques durs portable.



Pour les M3U, tu les partages avec l’application comme sur iOS <img data-src=" />







Mais ton m3u te donne une liste de fichiers… Que tu peux pas ouvrir sans FilePicker…


Le 30/01/2014 à 14h 07







Lafisk a écrit :



Ouai enfin tu peux pas non plus faire de l’immobilisme, win32 devait finir par degager, le boulot de dev a toujours ete comme ca.







Les threads, les sockets BSD ou les fopen, c’est pas Win32. Tous les autres OS ont ces fonctions, sauf WinRT.







yeagermach1 a écrit :



Il manque des choses je suis bien d’accord. Mais par exemple :





  • l’absence de socket BSD est compensé par d’autres sockets





    C’est faux et archi-faux. Les nouveaux sockets ne permettent pas de faire tous ce qu’on pouvait faire avant, à moins de trixer comme des porcs.



    Sans parler du fait que les nouveaux sockets sont codés sur les anciens… Puisque les drivers sont codés pour les anciens…







    yeagermach1 a écrit :



  • le non accès aux fichiers c’est le principe de l’appli bac a sable. C’est très chiant j’en conviens, mais comme sur iOS le partage de fichier pour une application existe.







    Et tu ouvres comment un fichier de playlist? Hein, juste un m3u? Ah bah, tu peux pas…







    yeagermach1 a écrit :



  • C’est pareil pour les IPC, l’accès aux devices.







    Désolé, mais non. Justement, pour les sandbox, tu as des IPC pour discuter entre applis. Et quel est l’intérêt d’interdire l’IPC pour la sécurité?



    Les devices, j’en parle même pas… Comment tu affiches une webcam? Comment tu lis un DVD?

    En quoi interdire la lecture d’un device améliore la sécurité?


Le 30/01/2014 à 13h 52







lossendae a écrit :



Ayant un rapport avec le développement de cette nouvelle version de VLC ?





Oui.


Le 30/01/2014 à 13h 52







Edtech a écrit :



Car en fait, il ne faut pas chercher des équivalences ! Il faut penser autrement.







Aka, il faut tout recoder.



Toutes les libs utilisées par tout le monde depuis 30 ans sont inutilisables.



Après faut pas s’étonner que les dev ne travaillent pas sur la plate-forme…


Le 30/01/2014 à 13h 30







lossendae a écrit :



Je n’espère pas, tu devrais en faire un article pour PCI, le point de vue d’un dev sur Windows 8.







No way.



Par contre, je vais faire un article sur Microsoft, notablement Microsoft France, qui ne sera pas piqué des vers…


Le 30/01/2014 à 13h 20







the_Grim_Reaper a écrit :



Pas vu sur le site de videolan, j’ai mal regardé ?







Le site web… comment te dire… C’est pas vraiment une priorité.


Le 30/01/2014 à 13h 19







yeagermach1 a écrit :



Sans troll, en quoi le portage a été si compliqué ? API pas au point ? Pas le droit d’utiliser des bibliothèques que vous utilisiez pour d’autres OS ? Plus de travail de réécriture que prévu ??





C’est un OS où tu:







  • n’a pas de threads corrects,

  • n’a pas de sockets BSD,

  • n’a pas d’IPC,

  • n’a pas de clock de timing,

  • a une stack audio incomplète, et sans background simple,

  • n’a pas d’accès aux fichiers, pas de fopen,

  • n’a pas d’accès aux devices,

  • a tout en Async, mais les APIS sont souvent bugguées,

  • a plein de bugs dans l’UI et dans les tools,

  • une documentation souvent fausse ou très incomplète,







    Ça fait tout de même beaucoup pour une seule plate-forme. Et oui, après ce post, ça va partir en troll…


Le 30/01/2014 à 13h 12







the_Grim_Reaper a écrit :



D’ailleurs vous n’avez même pas dev pour AIX et HP-UX ! <img data-src=" />

<img data-src=" />





Si si HP-UX.


Le 30/01/2014 à 12h 56







the_Grim_Reaper a écrit :





  • Win ME



    • Vista

    • Win 8 - 8.1

    • Ubuntu Unity

    • iOS





      T’as oublié Android et OS/2







      Chloroplaste a écrit :



      Une petite sortie sur xbox One également et finit le problème de lecture des mkv !

      Je croise les doigts pour que ça finisse par arriver.







      Y a pas de SDK ouvert :)



Le 30/01/2014 à 11h 39







kikoo25 a écrit :



Mais quelle est donc cette vidéo “Boobies” sur la première image de l’article ? <img data-src=" />







Tu la veux? <img data-src=" />


Le 30/01/2014 à 11h 32







arno53 a écrit :



Les commentaires sur Neowin et WinBeta était assez négatif vers la durée du projet… Ils n’ont pas forcément compris le principe du financement participatif…







Ça, c’est sûr qu’ils n’ont pas compris… Mais bon, ça a été vraiment dur ce projet… Et pourtant on a porté sur plein d’OS pourris…


Le 20/01/2014 à 17h 29







link689 a écrit :



si ca crash qu’a se moment la moi ça me gêne pas perso mdrr

c’est une des principale utilisation que je veux faire de ma tablette regardé des films et utilisé les flux réseau tel que celui de free.fr







Je crois que je m’approche du fix :)


Le 15/01/2014 à 11h 56







arno53 a écrit :



J’avais cru comprendre quevous aviez l’audio … C’est Windows 8.1 qui a rajouter ce bug via des API interdites qui ne l’étaient pas avant ?







On a de l’audio, mais ça crashe sur certains devices, au moment du quit.


Le 14/01/2014 à 00h 37







Ziou a écrit :



Vivement le support amélioré de l’UPnP.

P.S : j’arrive pas a accéder a mon synology avec vlc





lequel?


Le 13/01/2014 à 18h 06







alegui a écrit :



Et la version android pour qu’elle devienne stable?







Après la fin du redesign. Probablement en février. Avec l’accélération matérielle complète…


Le 13/01/2014 à 17h 15







yeagermach1 a écrit :



Et la version Winrt ? ModernUI ?







Toujours bloquée par le même bug audio qui empêche de rentrer dans le store.


Le 15/01/2014 à 11h 16

Euh, par contre, comment dire, c’est chiffré sur les devices?

Le 09/01/2014 à 19h 02







yl a écrit :



Bizarre, si le source de FF était truffé de pointeurs casté cochon, ca devrait poser pb qqsoit la plateforme. Pourquoi ce pb propre à windows? Le même que VLC niveau compilo 64 bits?







Oui. Exactement le même. Mais mingw-w64 marche bien de nos jours, donc plus de raisons.


Le 09/01/2014 à 08h 55







methos1435 a écrit :



Je sais bien… Disons qu’ils prévoient la possibilité de… dans les standards. Mais dans la réalité, dès lors qu’ils autorisent le CDM à effectuer le rendu, j’ai du mal à imaginer les fournisseurs de contenus protégés autoriser le navigateur à avoir accès à des données qui ne sont plus sécurisées…



On va se retrouver avec un joli simili lecteur flash sans autre contrôle que d’avoir à placer une balise video…







Donc, tu comprends bien comme moi… Ça va être joli comme design :)


Le 08/01/2014 à 22h 01







methos1435 a écrit :



Parce que je lis sur leur schéma que le CDM peut avoir la possibilité d’effectuer lui même le rendu.



Et j’ai du mal à voir les fournisseurs de contenu accepter qu’il en soit autrement. Laisser le navigateur (d’après leur schéma) en possession de frames déchiffrées et sans protection ? Laisser la possibilité de modifier le navigateur pour rediriger le contenu non protégé vers un fichier ? …







Et comment tu overlay des divs au dessus? Comment tu fais des transfo CSS sur la vidéo dans ce cas là?



Moi, c’est ça qui me gène, surtout.


Le 08/01/2014 à 20h 02







methos1435 a écrit :



Qu’appelles tu frame-backs ? La façon de récupérer les frames déchiffrées ?







Oui.


Le 08/01/2014 à 19h 34







methos1435 a écrit :



Oui mais le CDM se trouve coté client ? (vraie question, j’ai un peu de mal à voir le fonctionnement global.





Oui.







methos1435 a écrit :



Le CDM parle avec le serveur et le navigateur parle au CDM ?).





Je crois que le navigateur parle avec le serveur et avec le CDM et forward les info du serveur au CDM.







methos1435 a écrit :



Donc même si la “communication” entre le navigateur et le CDM est standardisée, je vois pas en quoi cette standardisation apporte du bon dans tout ça. Rien n’empêche le fournisseur de contenu de ne fournir un module que pour un OS donné. Le vrai problème, pour moi, du DRM actuellement, c’est pas tellement le principe même de DRM, c’est le manque d’interopérabilité. Si une pseudo standardisation ne résout pas ce problème, ça n’améliore pas la situation pour l’utilisateur final.







Malheureusement, de ce que j’en comprends, c’est pas vraiment clair ce que ce standard apporte, car ça enlève “juste” flash, mais y a pas de standardisation des calls.



Et je ne parle pas de la question sur les frame-backs depuis le CDM.