-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Múltiples streams en un m3u8 #17
Comments
Dándole vueltas al tema de las diferentes calidades de vídeo para el mismo canal. Mi idea era indicar en las preferencias del plugin cual es tu calidad de vídeo preferido. Entonces el plugin eligiera con los streams disponibles cual debe cargar. A todo esto desconozco en cuanto a la API kodi tanto las preferncias como seleccionar differente stream del mismo m3u8. Si alguien tiene alguna referencia de codigo... seria bienvenida |
Tambíen pensé meter directamente los differentes streams en el JSON con sus diferentes calidades. |
Sería contraproducente añadir eso al JSON creo yo.
Encima de cada stream, hay metainformación. Lo ideal es extraer de ahí todo
cuando se presente al usuario.
Hay dos escenarios: En el primero, cada canal tiene otro menú para las
resoluciones. Ahí se cogería la información de los metatags.
En el segundo, el usuario lo define en preferencias. En ese caso, coger
automáticamente el de la mejor resolución. Si no hubiese metatags, he
observado que suelen estar ordenados de menor a mayor resolución. Coger el
último.
Salu2
El 20 nov. 2017 8:33 p. m., "urnenfeld" <[email protected]> escribió:
Tambíen pensé meter directamente los differentes streams en el JSON con sus
diferentes calidades.
"url_hd" : "http://....",
"url_sd" : "http://....",
"url_720" : "http://...."
...
@vk496 <https://github.com/vk496> dominas mejor esta tecnología, sería un
enfoque correcto?
—
|
Con escenarios me refiero a posibles implementaciones. En mi caso, opto
también por un menú de preferencias en vez de cada canal.
Salu2
El 20 nov. 2017 9:15 p. m., "Valentin Kivachuk" <[email protected]>
escribió:
… Sería contraproducente añadir eso al JSON creo yo.
Encima de cada stream, hay metainformación. Lo ideal es extraer de ahí
todo cuando se presente al usuario.
Hay dos escenarios: En el primero, cada canal tiene otro menú para las
resoluciones. Ahí se cogería la información de los metatags.
En el segundo, el usuario lo define en preferencias. En ese caso, coger
automáticamente el de la mejor resolución. Si no hubiese metatags, he
observado que suelen estar ordenados de menor a mayor resolución. Coger el
último.
Salu2
El 20 nov. 2017 8:33 p. m., "urnenfeld" ***@***.***>
escribió:
Tambíen pensé meter directamente los differentes streams en el JSON con
sus diferentes calidades.
"url_hd" : "http://....",
"url_sd" : "http://....",
"url_720" : "http://...."
...
@vk496 <https://github.com/vk496> dominas mejor esta tecnología, sería un
enfoque correcto?
—
|
Buenas, He actualizado el formato de JSON en https://github.com/vk496/TV-Online-TDT-Spain/tree/develop De esta forma, es posible contemplar diferentes m3u8 para un mismo canal. Me parece que no es necesario ahora mismo, pero cuanto más tarde se haga, más difícil será extender esa funcionalidad. Salu2 |
Hace falta algun campo estilo "tags"/"flags" que pudiera contener información como HD/SD/dynamic/dirty aparte de dar información de la naturaleza del link, el plugin también podría tomar decisión cual elegir en base a esa información. e.g. ahora mismo habría que tratar la lista pero al no haber mas información habria que reproducir el primero... |
Sigo creyendo que ese campo no es necesario. Tener dos campos en la configuración: "Habilitar HD" y "Caldiad Preferida" La primera vez que obtienes el m3u8, si hay varias calidades, van ordenadas de menor a mayor (hasta ahora, no he encontado un contraejemplo). Si el user no tiene habiliado HD, se coge el primero (la calidad más baja), y para alante.... Si tiene habilitado HD, se intenta coger el stream con calidad igual o menor al escogido. De esta forma, se evita sobrecargar el JSON con información que puede variar en cualquier momento y que requiere mucho más mantenimiento, que si se hace de forma dinámica. Salu2 |
Aunque no tenga ejemplos, no puede haber una URL/m3u8 que solo contemple 1080 y otra que solo cubra 720? Aun así la propuesta iba más en la idea por ejemplo ejemplo que hemos visto con Euronews. En ese caso la URL no sería el m3u8 directamente sino la URL desde donde lo podriamos extraer. Un canal que emite por youtube seria otro ejemplo. |
Buenas, Creo que no me explico bien. Voy a intentar explicar nuevamente el caso hipotético que propongo: En KODI, si habilitas HD, tendrás una nueva pestaña para elegir calidades:
En el caso de Euronews, tiene un URL genérico, en el que accedes a cada stream en base a su calidad de emisión. Asi pues, sabemos que tiene las siguientes:
Como tenemos seleccionado 1080p, y no tiene esa, probaría la siguiente: 720p. Si obtenemos el m3u8 de esa calidad, nos lleva directamente a la emisión, asi que todo OK:
Sin embargo, no todos los canales funcionan así. Algunos cómo Antena3, lo tenemos con un m3u8 "maestro":
Considero que no tiene sentido definir en el JSON algo que te devuelve de forma dinámica, porque en cualquier momento te quitan una y se acabó el invento. Además, del mantenimiento que supone con cada canal. Hay dos opciones: O definimos nosotros una forma dinámica de manejar eso (con la metainformación que ofrece), o delegamos directamente en
Comentar que si se trabaja con streamlink, sería interesante ver si es posible pasarle la tubería unix a KODI, en vez de la URL. Lo digo porque desde KODI no he visto dónde se definen parámetros de buffer y otras cosas, mientras que en Salu2 |
@vk496 Te entiendo, Creo soy yo el que no me explico. De la primera parte de mi comentario:
La segunda parte(Euronews):
Otro ejemplo aunque no estoy al 100% seguro: Una tipica URL youtube(emision en vivo), los reproductores no la van a procesar, Tenemos que decirle al plugin que invoke al plugin youtube para poder reproducirlo(Creo que streamlink tambien sabe gestionar estos) ej:
En resumen si tenemos varias URLs para el mismo canal, de alguna forma debemos poder marcar porque hay varias, ya que puede haber razones útiles que van mas allá de un simple enlace alternativo. Es como decias al principio estar prevenidos para posbiles casos y que despues sea más trabajoso cambiar. Aprovecho, que estamos en temas profundamente tecnicos: Para el ejemplo de Nova tenemos:
Pero existe:
(Curiosamente dentro de estos m3u8 veo las mismas resoluciones en todos) por lo tanto ahora mismo podria pensar que son enlaces alternativos... Conoce alguien esos acronimos hds/hls/lds? Salen estos links de OTRO m3u8 padre??? y Por ultimo: Donde seleccionas eso de HD en KODI??? :P a ver si lo voy a tener activado... |
Vale, ya nos vamos entendiendo. De lo primero que comentas, sip, en ese caso habría que hacer lo que tu dices. Pero me sorprendería que el Respecto al flags, lo he pillado. Yo había adaptado el JSON para dar más flexibilidad: https://github.com/vk496/TV-Online-TDT-Spain/blob/develop/tv-spain.json Mi idea era convertir el campo link_m3u8 en un array, con sus propiedades correspondientes. Creo que cambiando el campo dirty sería suficiente. El indicar calidades dentro el JSON, lo pospondría lo máximo posible. Cómo ya he comentado antes, incluir eso, supone un incremento brutal de mantenimiento. Y si al final nos lo podemos quitar porque no hay cadena que haga uso de ese sistema excéntrico, mejor para nosotros. Respecto a lo de A3, ni idea... Pero se podría añadir como una fuente del canal más en el esquema que tengo en desarrollo. Habría que definir el comportamiento cuando un canal tiene múltiples fuentes. sobre el campo HD en KODI, no existe. Es mi propuesta para añadir esa opción en la parte de configuración del addon. Salu2 |
Todo claro!
Efectivamente, sólamente había visto que un solo flag "dirty" no iba a cubrir todos los casos. Veo 2 enfoques:
Esta claro que algunos son excluyentes, y al ser JSON todo es opcional. Pero personalmente me gusta más la segunda opción, ya que el código necesario para procesarlo es mas limpio. Tambien creo que es más flexible. |
Siguiendo investigando sobre este tema. Tengo en mi caso que si reproduzco con VLC, sí efectivamente coge el primer stream del m3u8, hasta aquí ok ya que me coge un stream de 720. Sin embargo, Kodi, se empeña en seleccionar 1280, el mejor. Al ver que no encontraba nada en la API ni en otros plugins, me disponía a abrir una consulta en los foros(ya que me resulta imposible que kodi no sea capaz de gestionar un m3u8), pero encontré lo siguiente: https://forum.kodi.tv/showthread.php?tid=296611&highlight=m3u8 Resumiendo, Kodi escogerá el stream dependiendo del ancho de banda que tenemos seleccionado en las preferencias: (System Settings, Internet, ...) Seleccionado el minimo posible (512kbps) consigo que algunos streams bajen a los 720. |
Por lo que tengo entendido, si se usa la API de Streamlink, tenemos un control completo sobre el stream y detalles como esos. Aquí más info: https://streamlink.github.io/api_guide.html Salu2 |
Sí, estuve indagando, de hecho existe un plugin de streamlink: https://github.com/beardypig/plugin.video.streamlink El problema únicamente se resume a resolver la dependencia de tener el paquete streamlink en el sistema o depender de este plugin. Mirando por dentro streamlink, no es magia, es esfuerzo. Me explico, me dio la impresión que utilizaba algun metodo standard para extraer el stream, pero no, son scripts python particulares que hacen ingeniería inversa para cada pagina que soporta: Eso si, son muy didácticos y ahí hay impresionante trabajo contenido en pocas lineas! Deberíamos tener una lista de canales que obtendríamos por este método, para evaluar cuanto nos va a aportar el esfuerzo. Los canales de mediaset no se pueden extraer a día de hoy... así que no conozco que otros aparte de euronews :( |
Buenas,
Hay algunos m3u8 que definen distintas calidades para el mismo Stream (Neox por ejemplo). Creo que se podría añadir un booleano al JSON para contemplar esos canales y mostrar al usuario el menú con las resoluciones disponibles.
The text was updated successfully, but these errors were encountered: