Veo muy probable que esos congelamientos se produzcan precisamente por lo de las listas de reproducción que comentas. En efecto, con los m3u8 la CPU se me dispara a 100%, mientras que con los rtmp no me da ningún tipo de problema ni empanamiento.
Y lo he estado probando en diferentes versiones del Windows 7 (Home, Professional...), y hasta en Windows XP!!!!!! y siempre me ocurre lo mismo. Y no creo que sea por el ordenador o incluso por la velocidad de conexión, así que me doy por vencido, y quizás deba utilizar el MPV hasta que el VLC se digne a solucionar esto.
Los drivers que necesitarían mis ordenadores no tienen soporte para Windows 7, por lo que utilizo otros de la misma marca (ATI) y no me suelen dar problema.... no sé si tendrá mucho que ver con el empanamiento en los m3u8 en VLC... aunque todo sumará, y si ese es el problema a solucionar me quedo tranquilo.
Lo podría haber investigado el otro día que le puse fugazmente XP, ya que sí que hay soporte para ese sistema operativo, pero bueno.
chicos dentro de poco habra q actualizar los SO al windows 10 lo sacan el 29 de julio yo por suerte estoy haciendo pruebas cuando saquen el final seran unos 300€ mas o menos
acojonante todos los operadores son iguales este donde este tengo problemas con el wifi
Yo he hecho pruebas con VLC, SimpleTV y Media Player Classic Home Cinema con varios tipos de emisiones online indicadas a través de listas de reproducción M3U8, y me parece que el problema que se indica no tiene nada que ver con el uso o no de la aceleración de hardware o el procesamiento de imagen por software. Estoy de acuerdo con la explicación de RVM, a la que le añado algunas puntualizaciones:
La cuestión es que algunas listas de reproducción M3U8 redirigen a rutas HTTP únicas, con un único stream que cargar, por lo general, en formato FLV; por ejemplo, las que pasan por los servidores de Flumotion, como pueden ser las señales online de Canal Sur Andalucía o Castilla-La Mancha Televisión. Estas emisiones indicadas a través de M3U8 no consumen apenas recursos, ya que sólo hay que centrarse en cargar un archivo y descodificarlo, exactamente igual que pasaría con una emisión en cualquiera de las variantes de RTMP.
Sin embargo, existen unas emisiones indicadas a través de listas de reproducción M3U8 que no son para una ruta HTTP única, sino que consisten en muchas rutas HTTP que son cargadas de forma dinámica una detrás de otra, juntándose en vivo para que nosotros veamos la emisión fluida. Por ejemplo, esta señal online de La 1 que habéis puesto, o las señales online de LaLigaTV o de los canales de Televisió de Cataluña, son basadas en listas de reproducción M3U8 con rutas HTTP cargadas una detrás de otra, y además, en formato TS, casi como si fuera una emisión de TDT, aunque no con tanta calidad.
El problema que yo creo que ocurre es que estos programas, cuando detectan una lista de reproducción de este tipo, intentan cargar de forma anticipada todo el contenido indicado en el archivo M3U8, como si ya existiese previamente, con la finalidad de aligerar posteriormente tiempos de carga. Esto, que podría servirles si el archivo M3U8 redirigiese a archivos ya presentes en nuestro PC (por ejemplo, una típica lista de reproducción de archivos de música) o a archivos online ya existentes, no les es tan útil en el caso de estas emisiones en vivo, y creo que, como no pueden cargar los siguientes archivos indicados en el M3U8 al no existir en ese momento, pues aumentan de forma importante el consumo de recursos, como si se forzasen a cargarlos o dependiera de los propios programas el poder acceder a dichos archivos, cuando en realidad tendrían que esperar a que el servidor los envíe.
Y el ejemplo más claro de que esto es así es lo que RVM, acertadamente, ha indicado con su explicación y sus capturas. El reproductor mpv, al estar bien preparado para no intentar precargar estas emisiones online antes de tiempo, no gasta más CPU de la necesaria; mientras que VLC, al intentar precargar todo el contenido posible del archivo M3U8 y no estar éste disponible en ese momento, pues aumenta innecesariamente los recursos y se dispara el uso de CPU.
En mi caso, utilizando VLC y SimpleTV, compruebo que las emisiones indicadas en M3U8 con un link único usan muy poca CPU, ya que no se tiene que molestar en cargar más contenido de otros links; sin embargo, las emisiones indicadas en M3U8 con varios links que se cargan uno detrás de otro, disparan el uso de CPU en ambos programas, y es porque están pensados para forzarse a precargar todo el contenido posible, y en realidad no pueden hacer nada, dependen de que el servidor envíe el siguiente fragmento de emisión.
Por su parte, en Media Player Classic Home Cinema, el uso de CPU en ambos casos es en torno al 10%, muy bajo, y ni se nota el "pegado" de un archivo TS tras otro.
Me temo que es imposible. VLC trata de esta manera los archivos M3U8, y a menos que los desarrolladores cambien este comportamiento, no se puede hacer nada. De hecho, en el link de Wikipedia que puso RVM, se indica que el soporte para M3U8 es parcial, y parece que a día de hoy se mantiene así.
Hay que tener en cuenta una cosa, y es que a mí el VLC que tengo instalado en Linux (VLC 2.0.3) me funciona perfectamente con ese stream de La 1, sin parones, y el consumo de CPU está en torno al 20%. Y esto es en un ordenador súper antiguo.
Es en Windows donde el uso de CPU es muy alto. Por si fuera un bug de versiones recientes, he probado a descargarme versiones antiguas del VLC y en todas pasa lo mismo.
Así que parece que este problema sucede sólo en las versiones para Windows del VLC.
Posible soluciones:
* usar otro reproductor
* comentarle el problema a los desarrolladores del VLC en su foro, a ver si lo arreglan u os dan una solución
Seguramente hayan preparado el uso de M3U8 de una manera teóricamente aceptable, pero el riesgo de estos proyectos multiplataforma es que en cada Sistema Operativo el comportamiento puede ser diferente en una misma acción, y si no es lo suficientemente testeado, puede acabar quedando como un bug crónico (este problema de VLC parece que tiene años), que sólo resolverán si mucha gente les acaba insistiendo (o a lo mejor no tanta, pero por desgracia suele ser lo más habitual).
Así que con esa información de RVM de que en Linux no da ese problema, está todo claro.
Yo te recomiendo Media Player Classic Home Cinema, que va fino fino filipino xD Con versiones de 32 y 64 bits, incluye su propio sistema de códecs interno (LAV Filters, también instalable externamente), aunque se puede personalizar muchísimo, y desactivar los que queramos, para que vía DirectShow pueda cargar códecs externos (puede ser que haya formatos que usen códec externo para reproducirse y en un reproductor como VLC no podamos verlos u oírlos, aunque no es lo habitual), y así mezclar y utilizar tanto interna como externamente los que nos interesen (por ejemplo, ffdshow para postprocesado del vídeo y/o audio), cosa que por definición no podrás hacer en VLC, aunque el propio VLC incluya muchas opciones. Además, junto con el reproductor, podemos instalar complementos especialmente pensados para él, como el renderizador de vídeo madVR, el renderizador de audio ReClock, el filtro avanzado de subtítulos XySubFilter, el proyecto para vídeo suavizado SVP e incluso Autofrequency para que, si usamos un proyector, cambie la tasa de frames del proyector automáticamente para ajustarlos al vídeo, y créeme, el resultado final con todo este pack merece la pena, y mucho.
Y quienes tienen ya reservada copia desde Windows 7 y 8.1 lo tendrán gratis en sus equipos desde hoy, aunque lo recibirán primero quienes hayan participado en su prueba a través de Windows Insider.