Portada
mis comunidades
otras secciones
#12:
Si tu perro se come el VHS de tu partido favorito... coje el zurullo y pasaselo al VLC, que te lo reproducirá en 4K
#3:
VLC , hasta lee los videos torcidos de los moviles, poniendolos derecho
#11:
#9 Lo jodido es que es verdad
https://www.vlchelp.com/rotating-video-in-vlc-media-player/
https://www.vlchelp.com/rotating-video-in-vlc-media-player/
#18:
A mí con que saquen el puñetero v3.0 con soporte a chomecast... a este ritmo saldrá antes Half-Life 3
#1:
a @cocopino. no le va a gustar nada esta noticia
Comentarios
VLC , hasta lee los videos torcidos de los moviles, poniendolos derecho
Si tu perro se come el VHS de tu partido favorito... coje el zurullo y pasaselo al VLC, que te lo reproducirá en 4K
#9 Lo jodido es que es verdad
https://www.vlchelp.com/rotating-video-in-vlc-media-player/
#2 pero, mucho peor, anuncian latas de atún en Javascript carísimas, en LIDL son en aceite de oliva y mucho más baratas
a@cocopino. no le va a gustar nada esta noticia
A mí con que saquen el puñetero v3.0 con soporte a chomecast... a este ritmo saldrá antes Half-Life 3
#1 Que pasa, que VLC lleva publicidad de Mercadona?
#4 Atún en Javascript???? Dame 1000
#13 Y a mi con que tenga "enviar a chromecast"
#5 No me seas atún
#3 suena a frase-meme de Chuck Norris...
😂
#6 A ver si te crees tú que sin el apoyo de HTML5 vas a poder hacer mucho una vez tengas los frames de audio y vídeo decodificados desde JavaScript.
#1 No necesita VLC, él mismo construyó este práctico sanitario con un cono del Lidl,
#6: Imgino que con un lienzo de esos, y mucho, pero que mucho procesador.
#20 No creo que yo tenga problemas de eso, mi procesador tiene tecnología MMX
¿ Y HTML5 cómo encaja con esto ?
#10 Para quemar micro como si no hubiera mañana. Decodificar vídeo por software en Javascript debe ser la mayor estupidez del siglo, en un sobremesa moderno a lo mejor tira bien, en un portátil o un móvil te funde la batería en media hora. Y no, WebGL no valdría de nada en este contexto, porque la decodificación hardware de vídeo va por otras APIs.
Yo estoy usando MPV con la interfaz gráfica SMPlayer y me va bien así. El VLC no lo he usando nunca, ni lo voy a usar ahora, ni lo usaré en el futuro.
#22 Hombre... aquí tienes un ejemplo de un decodec de Theora en JavaScript que funciona bastante mejor con WebGL (aunque habría que mirar con detalle cómo realiza el acceso a memoria de vídeo): https://brionv.com/misc/ogv.js/demo/#file=Paragus_sp_-_2013-08-10.webm
Nota: No me responsabilizo del calentamiento de tu micro al probar las diferentes opciones. El vídeo puede herir la sensibilidad de apifóbicos.
Voy corriendo a comprar un ventilador más grande para mi CPU...
Yo últimamente utilizo Smplayer.
De un tiempo a esta parte noto en varios de mis ordenadores (Ubuntu) que el VLC va más lento a la hora de decodificar vídeo que el Smplayer.
No, si la idea no es necesariamente mala pero... ¿Para qué? Porque, en mi opinión, por muy bueno que sea, descargarse un javascript de varios megas cuando el navegador ya soporta el (de)codec es bastante ineficiente. Además, está el tema de que JavaScript es un lenguaje interpretado. Así que, a menos que hagan que el procesamiento pase a la GPU (con WebGL/WebCL), no le veo mucho sentido.
No sé. No le veo la utilidad al proyecto. ¿Alguien puede aclarar esto?
#16 ¿por qué? Si precisamente el proyecto va de decodificar el stream a pelo en javascript, sin utilizar la funcionalidad de decodificación del navegador de turno...
#10 Un ejemplo que ahora me afecta. Si quiero acceder a mi música almacenada desde una interfaz web, o esta en un formato que entienda el navegador, o tengo que recodificar los ficheros (ej. Flac), mientras que con esto me ahorraría dicho problema.
#10 Ya que nadie te ha respondido en serio, la respuesta correcta es archivación. Para preservar una cantidad enorme de datos, por ejemplo de the internet archive, con todo tipo de formatos de lo más raros. Sí, la opción más eficiente para el cliente es convertir y que se le envíe el video o audio en un formato que soporte el navegador. Pero hacer eso con todos los archivos multimedia y con varios navegadores puede resultar prohibitivo, tiene pérdidas y los formatos actuales pueden quedarse obsoletos. Mientras que JS siempre funcionará en todos los navegadores del futuro, y las versiones de VLC que reproduzcan específicos formatos pueden ser guardadas en JS directamente.
#45 Os veo informados, creeis que mi 486 podra con ello? Y si le pongo el turbo?
Pues a mi VLC en Linux tambien me va bastante mal. Sobretodo algunos formatos que ahora estan más de moda, tipo MKV, va o bien horrible o a 10 FPS. Yo tambien uso SMPlayer.
#13 Yo con que leyera archivos .m3u8 y las listas .xspf que sí hace el de escritorio
#21 Mi madre lo llama "doble surraun".
#40 El MMX es mejor, tengo un Pentium II
#44 el slot es el futuro, no tiene sentido que vuelvan a la antigua tecnología del socket, no hay marcha atrás
#52 aunque el 486 sigue siendo una buena máquina se está empezando a quedar anticuado, necesitarás actualizar a algo que almenos tenga tecnología MMX como algunos pentium 1 . Pero puedes pillarte uno de estos así te ahorras cambiar la placa, memoria etc...
#39 No se usa SSE para eso?
#41 SSE se introdujo en Pentium III, cierto
#43 Dicen que para la próxima generación siguen con el slot, pero que lo mismo más adelante se plantean volver al socket
#36 Lo mismo aquí. Hace 3 meses cambié de VLC a mpv + smplayer y mano de santo.
#2 No pasas el suficiente tiempo en Meneame sino conoces las especificaciones del ordenador de@cocopino
#31 Si WebGL puede ayudar, pero todas las GPUs modernas implementan decodificación de ciertos codecs por hardware, y a eso no se accede a través de shaders, sino con APIs específicas que no creo que estén disponibles en Javascript. Con WebGL podrías implementar la DCT y la conversión de espacio de color, pero muchas otras partes de un codec moderno como CABAC son imposibles.
Qué felicidad se respira, pero seguro que lo aplicaréis al porno.
¿Y para cuándo el soporte para Chromecast?
Impresionante el VLC...funciona a tope.
Hasta que no lo hace y tiras del Media Player Classic, que ese si tira.
#0 A mi con que la versión de Android le metieran lo de "listar radios online" estaría muy contento.
#12: Y con sonido cinco punto uno.
#30 Si no fuese por lo que hemos aprendido en esos vídeos...
#8 mas bien sin html5 no tienes frames decodificados
#23 Sin html5 como lees ese stream?
#18 Para windoze creo que tienes las betas con soporte de chromecast. Esos night nosequé.
Para Mac seguimos esperando.
#46 Gracias. Tengo que ponerme al día en cuanto a codecs, pero tu comentario es muy informativo. Después de mirarlo por encima, es cierto que algo como CABAC no se podría paralelizar bien con shaders.
#49 Ummm... Es un buen motivo, pero no me fío tampoco de que JavasScript (ECMAScript) vaya a seguir siendo soportado a medio-plazo por los navegadores web (si es que seguimos usándolos para entonces). Sinceramente, me fío más de los sistemas de retrocompativilidad en los decodres/demuxers, aunque haya que recompilarlos para otras plataformas.
#9 Si te has bajado un vídeo digamos ejem "educativo" y te da problemas prueba con el VLC, si ese no lo abre es que no lo abre ninguno.
#10 Porque se puede...
#46 Eso cuando tienes el lujo de leer un codec actualmente popular. Véase #49.
#55 La gran ventaja de JS respecto a los demás lenguajes y plataformas es precisamente la compatibilidad. No van a romper eso los navegadores en muchos años (si es que alguna vez pasa).
Y si rompen alguna API que usaba Emscripten, harán un polyfill que arreglará todas las versiones de VLC que hayan compilado hasta la fecha (por tanto arreglando el reproductor de codecs desconocidos de los que nadie se acuerda). Las API estándar son mucho más fácil de mantener funcionando para la eternidad que las propietarias (como las de MSIE que tanta lata nos dio a los web devs). Muy especialmente cuando la funcionalidad usada es muy elemental (leer stream, crear framebuffer donde escribir el resultado) y nada de CSS ni cosas así.
En otras palabras, yo al revés que tu, me fio mucho más de la compatibilidad con JS (o WebAssembly que actualmente se traduce a JS) que en que se mantengan la inmensa cantidad de decoders/demuxers.
Para que te hagas una idea, yo he desarrollado una aplicación web, con una parte de funcionalidad muy complicada en C++. Al testear en navegadores menos usados como Safari y Edge, tengo mil problemas, pero ninguno relacionado con la compatibilidad de ese código C++. Si hablamos de rendimiento ya es otra cosa, pero eso no es un problema en el objetivo de preservar datos.
#30 MPC HC
#53 Uff, es que 46000 pesetas es mucha guita, pero bueno si me aguanta unos 4 años mas pues perfecto.
#42 El Pentium III aún no ha salido, eso debe ser la bomba
Siempre he amado esta aplicación es excelente realmente.
#33 ¿No falta un al final de tu comentario? ¿O es que lo dices en serio?
#35 ¿Te lo repito?