Imagen


Hoy os traemos una nueva actualización de la noticia de hace unas semanas sobre el maravilloso trabajo de Philipp. Como sabéis, está trabajando en actualizar el gestor de ventanas en Kodi bajo Linux, pasando de X11 a Wayland; como su proyecto ya está publicado, os lo vamos a intentar desmigar aquí en esta noticia con sus propias palabras.

Soporte para Wayland - yol

Mi objetivo principal era simplemente conseguir que Kodi soportara de forma nativa a Wayland, si es posible, tal y como hace actualmente con X11. El protocolo Wayland está ganando enteros, de forma lenta pero constante, en el mundo de Linux como sucesor de X11 y se considera generalmente como la opción ideal para sustituirlo a largo plazo; por ello considero esencial que Kodi migre también a Wayland si quiere seguir ofreciendo una buena experiencia en Linux. Como algunos sabéis, Kodi ya tenía una implementación de ventanas de Wayland originalmente escrita por Sam Spilsbury durante el GSoC 2013, pero fue eliminada de la rama master por razones de infraestructura no resueltas hace algún tiempo y nunca estuvo a la altura de la implementación de X11.

Junio

Subdividí el objetivo principal en una serie de sub-objetivos / características en mi propuesta inicial categorizada como "básica" (es decir, necesaria para que pueda el sistema al menos funcione), "adicional" y "posible extensión". En el primer mes, me ocupé de todos lo básico y algunas de las características adicionales. Había planeado salvar tanto del código anterior como fuera posible, pero finalmente tras varios cambios importantes, el código se volvió a escribir de 0. Aún así, frecuentemente revisaba la implementación previa para ver qué partes de Kodi tengo que tocar y cómo puedo solucionar algunos aspectos específicos.

Para conseguir algo más concreto, donde el acercamiento difiere más es en cómo los objetos del protocolo de Wayland se utilizan en C ++ orientado a objetos. Anteriormente se utilizaba un enfoque propio, probablemente porque no existían enlaces C ++ para libwayland-client en ese momento. El código resultante es bastante tedioso para escribir y mantener, por lo que decidí usar la biblioteca C ++ waylandpp como base. A pesar de que todavía no está muy maduro, pensé que era mejor opción para ahorrar algo de tiempo. Por supuesto, es posible usar la API C de libwayland-client directamente, pero no es muy buena idea, ya que el protocolo Wayland está realmente hecho para ser utilizado de forma orientada a objetos si el lenguaje lo permite . Para mi mayor deleite, el autor de waylandpp fue muy agradable y continuamente me ayudaba, lo que significa que todas las mejoras y adiciones de características que he hecho a waylandpp en este momento ya están fusionados en Github.

Desafortunadamente, pronto se hizo evidente que la infraestructura de ventanas de Kodi no está enfocada a Wayland, ya que hace algunas cosas de una manera muy diferente. Wayland está diseñado para que los clientes tengan un control mínimo sobre el escritorio por razones de seguridad. Esto, por ejemplo, significa que, a diferencia de X11, Windows y la mayoría de los sistemas de ventanas, las aplicaciones no pueden establecer modos de vídeo arbitrarios. Sólo pueden decir cuál sería su preferencia para el compositor, que luego decide y, a su vez, les dice a las aplicaciones qué tamaño pueden aplicar. Creo que esta es una buena decisión de diseño, ya que resuelve una gran cantidad de problemas que tiene XRandr (como dejar el escritorio en una resolución errónea cuando un programa se bloquea), pero sí significa que un montón de cosas tienen que hacerse de manera diferente. El código Kodi asume el procedimiento tradicional de buscar una lista de resoluciones válidas y luego poder cambiar a cualquier resolución de forma inmediata y básicamente sin fallos. Cambiar esto de una manera satisfactoria requeriría un montón de trabajo además que tendría que tocar todas las implementaciones de ventanas actuales. Eso es muchísmo trabajo, requiere coordinación con todos los mantenedores de plataformas, y no es realista que se complete dentro del marco de tiempo del GSoC, por lo que por ahora, he decidido intentar hacer los ajustes mínimos al código que permite Wayland para trabajar sin afectar a ningún otro sistema de ventanas. La desventaja de esto es que el código de Wayland no es tan limpio como podría o debería ser y que hay un mayor riesgo de introducir bugs.

Imagen


Julio

Después de tener listas la mayoría de las cosas básicas en junio, me centré en los dos grandes temas restantes: Soporte para la extensión del protocolo wp_presentation Wayland y el dichoso gestor de ventanas, el primero de los cuales se fusionó esta semana. En pocas palabras, Kodi ahora tiene una manera de determinar cuánto tiempo requiere para procesar un video hasta que aparezca en la pantalla y ya no es necesario que recurra a la suposición, mejorando la sincronización de AV. Además, puede utilizarse como fuente para el reloj de referencia de vídeo de modo que se puedan corregir ligeras discrepancias de los fps de vídeo con la velocidad de actualización de pantalla mediante el remuestreo del audio.

También he estado trabajando en el gestor de ventanas durante todo el mes. Supongo que normalmente no se esperaría que fuera un tema complicado, pero la mayoría de los compositores de Wayland requieren aplicaciones para dibujar y manejar las decoraciones de las ventanas, si quieren tenerlas. He discutido con mi mentor sobre cómo podría implementarlo y decidimos una vez más mantener las cosas, intentando tocar lo mínimo; por lo tanto hemos usado la implementación de Wayland y dibujado las decoraciones allí, así no afectamos a ningún gestor de ventanas existente. La otra opción habría sido de alguna manera integrar las decoraciones en el sistema de desollado de Kodi. Eso realmente era mejor idea, pero mucho más complicado y probablemente no vale la pena el timepo a invertir para solucionar ese pequeño problema. Como Mediacenter, la mayoría de los usuarios utilizarán Kodi en modo de pantalla completa, que también es el predeterminado, por lo que las decoraciones de ventanas no serán un gran problema.

Durante los últimos dos meses también tuve que aprender que Wayland sigue estando en desarrollo y por lo tanto tiene bastantes bugs. Tuve que informar y arreglar varios bugs en compositores y otros componentes de terceros como weston y libva. Encontrar estos errores y determinar de quien es la culpa me tomó más tiempo del que había previsto inicialmente. Me gustaría dar las gracias a la comunidad de #wayland IRC y específicamente a pq y SardemFF7 por su tiempo y consejos que me ayudaron a avanzar varias veces.

Agosto

En las últimas semanas he terminado el modo de ventana; también he estado investigando algunas cuestiones no directamente relacionadas con Wayland, como la manipulación de la pantalla táctil. Espero que no aparezcan grandes problemas que puedan impedir la fusión, pero soy optimista: la solicitud, al menos, ya está activa: https://github.com/xbmc/xbmc/pull/12664. Aparte de tener que poner los comentarios con los cambios, también estoy intentando identificar posibles pérdidas de memoria y mal uso de la multitarea y el multi-threading con valgrind y ThreadSanitizer.

Fuente de la noticia: https://kodi.tv/article/gsoc-2017-updat ... nd-support
LEER MÁS
Imagen

Ha pasado ya un tiempo prudencial desde que lanzamos la versión 17.3 donde ya habíamos arreglado varios problemas. Ahora ha llegado el momento de hacer otra en la que abordamos otros problemas que teníamos en el tintero. Aunque ya hemos avanzado con el desarrollo hacia de Leia (Kodi 18), no nos hemos olvidado de Krypton y por ello hemo hemos sacado esta nueva 17.4 para solucionar los problemas que hubiera.

Lógicamente, antes de sacar la versión final y estable, primero hemos querido lanzar la versión Release Candidate 1 para que un mayor número de personas pueda probarla y ver la estabilidad, bugs, etc. A continuación os dejamos con la lista de errores corregidos.

Correcciones hechas en esta versión

- Solucionado un fallo que podía provocar el cierre inesperado de Kodi bajo Windows, a causa de Python.
- Solucionado un fallo que podía provocar el bloqueo de Kodi bajo Windows, al habilitar Zeroconf.
- Solucionado un fallo que podía provocar el bloqueo de Kodi bajo Windows al actualizar o instalar addons.
- Arreglado el problema que provocaba Kodi en usuarios con proxys inversos que usaban websocket.
- Posible problema solucionado bajo Linux cuando usaba los codecs ffmpeg externos al reproducir contenido HEVC 10 bits.
- Ahora el scraper de música trabaja de forma escalonada para evitar sobrecargar el proveedor.
- Corregido el teclado nativo en iOS 11.
- Solucionado el error bajo Android O al cargar los iconos de la app.
- Ahora se muestra el banner de Kodi al abrir la app bajo Android O.
- Problemas de mapeo bajo Android -en algunos casos- solucionado.
- Kodi ahora detecta correctamente los codecs VP6 y VP8 bajo Android.
- Actualizado FFmpeg a la versión 3.1.9.
- Ahora es necesario que el hardware soporte la versión 3.1.X de FFMpeg para que Kodi funcione correctamente.
- Corregido problema de bloqueo al visualizar la grabación y presionar siguiente / anterior.
- Arreglado la identificación de álbumes y archivos de música mediante etiquetas usando el scraper.

¿Qué hay nuevo?

En las versiones enfocadas a la solución de bugs nunca incorporamos nuevas características. Por lo tanto y dado que las funcionalidades son idénticas a la versión Kodi 17.0, nada mejor que leer la noticia completa de Kodi 17 Krypton aquí aquí.

¿Dónde puedo descargar Kodi?

Como siempre, puedes encontrar la última versión disponible para su descarga en nuestra sección de descargas. Haz click en la plataforma deseada y abre el archivo descargado Puedes instalar estas nuevas versiones encima de la instalación que tengas ya de Kodi, sin realizar una reinstalación o una limpieza, ya que realizamos una migración completa de addons y base de datos si es necesario, por lo que no debería haber pérdida alguna de información. Todos los addons o skins instalados en la versión anterior, seguirán funcionando en esta 17.2 sin problemas.

Involúcrate

Involucrarse es bastante fácil. Simplemente sé valiente y da el paso al empezar a utilizar estas versiones Release Candidate de Kodi 17.1 Krypton. Si utilizas estas versiones, te animamos a reportar cualquier problema que tengas en nuestro foro primero y después en nuestro sistema de Trac (siguiendo esta guía: Cómo presentar un informe de error. Ten en cuenta que necesitamos información detallada para que podamos investigar el asunto. También agradecemos el apoyo en nuestros foros donde se puede donar a la Fundación KODI si quieres. Por supuesto, puedes también seguir o ayudar a promover Kodi en todas las redes sociales disponibles. Si quieres más información sobre Involúcrate, pulsa aquí.

Fuente: https://kodi.tv/article/kodi-v174-rc1-just-bunch-fixes
LEER MÁS
Imagen


Ahora que estamos a punto de terminar el GSCO 2017, hemos invitado a nuestro desarrolladores estudiantes a escribir sobre sus avances en el mundo de Kodi. Para los despistados, los tres proyectos de este año están implementando el soporte de shaders en Retroplayer, actualizando Kodi a Python3 para su soporte en addons, y haciendo que Kodi soporte de forma nativa Wayland (para sistemas Linux).

Empezaremos con la actualización de Nick en el tema del soporte de Shaders y os explicaremos las otras actualizaciones a lo largo de la semana.

Soporte de Shaders - Vel0cityX

Mi proyecto iniciar era sobre la implementación de shaders en Retroplayer, pero no solo centrándose en uno en concreto, si no que fuera capaz de soportar varios modos y métodos.

Sin embargo, rápidamente se me ocurrió algo más ambicioso: implementar la misma especificación que los shader de libretro usan. Esta especificación introduce un shader "preset" en los archivos. Éstos, simplemente son archivos de configuración que permiten múltiples opciones de shaders para lograr el filtrado deseado (o varios combinados), sin tener que usar el código de forma manual en todo el proyecto. Tienen otras características también, pero esa es su principal característica y por la que me animé a implementarlo. La mayor ventaja de implementarlo, es que ya hay mucho soporte y comunidad y por lo tanto hace años que está funcionando tanto para OpenGL (ES) como para Direct3D.

Por lo tanto, cambié mi proyecto inicial y me puse manos a la obra.

Para introducir un poco el tema, es importante mencionar que RetroPlayer no tiene su propio renderizador; Nunca lo tuvo. Toda su representación depende enteramente de VideoPlayer (el backend y renderizador utilizado al reproducir cualquier tipo de video en Kodi). Por lo tanto, estaba claro desde el principio que tendría que sortear este problema de una manera u otra.

Junio

El primer mes estuve muy ocupado con los exámenes universitarios, así que desafortunadamente mi tiempo dedicado a esto fue menos de lo que me hubiera gustado.

Nunca había trabajado en Kodi antes, así que al principio mi tiempo se dedicó a crear un entorno de desarrollo listo para programar (me encontré con muchos problemas en este punto), así como familiarizarme con algunas de las partes relevantes de la base de código.

A principios de junio, empecé a usar RetroPlayer por primera vez. Al instante noté algo que no me gustaba mucho: el escalado. Aparentemente, el renderizador de Windows no soportaba el escalado Nearest Neighbor, así que la primera cosa (productiva) que hice fue implementar dicho método en Windows. Tal vez no era algo directamente relacionado con mi proyecto, pero me facilitó la familiarización con una buena parte de la base del código, algo que me sería esencial para las próximas semanas.

Ya hacia mediados de junio y principios de julio, empecé a trabajar en un nuevo renderizador para RetroPlayer, que como os decía antes, tenía que estar basado en VideoPlayer si o si.

Julio

Tras la primera toma de contacto en junio, necesitaba que los preajustes del shader se cargaran. Tras un poco de ayuda de Garrett, decidí usar un addon binario que usa la implementación de RetroArch mediante la carga de archivos .cgp.

El inicio del mes de julio se dedicó a bucear en el mundo loco del desarrollo de addons binarios, creando un nuevo tipo de éstos, construyendo una API básica para él y haciendo que funcione desde dentro de Kodi. Todavía hay mucho trabajo por hacer al respecto, pero todo el marco está configurado ya y... ¡funciona!.

Hay cerca de 6 capas de abstracción entre el addon y lo que Kodi ve (!), Así que desafortunadamente cambiar la API es bastante tedioso (también depende del número de capas).

Sin embargo, era necesario, ya que el código de de RetroArch (el tema de carga de archivos .cgp) no era compatible con Kodi....hasta ahora.

Después de conseguir que funcionara, los cambios de Fernet en VideoPlayer causaron que mi renderizador fuera bastante inútil y necesitara una reescritura por completo. ¡Vaya por dios!

Sin embargo ya no tenía más tiempo para dedicarle al mismo tema, ya que suficiente tenía con mi proyecto inicial, así que decidí darle al tema un enfoque radicalmente distinto.

Sin entrar en tecnicismos, con el nuevo enfoque que le di al proyecto, RetroPlayer sigue siendo dependiente de VideoPlayer, pero menos. Bastante menos. Sin embargo, esta solución rápida, ha provocado que ahora no sea compatible con los nuevos cambios introducidos en VideoPlayer.

Hacerlo de forma limpia me obligaría a rehacer el renderizador copiando VideoPlayer de nuevo, es decir, empezar de 0 otra vez. Así que prefiero centrarme en tener el soporte de Retroarch en mi "versión" y cuando todo funcione perfectamente, hacerlo ya limpio en la versión final.

Si hay tiempo, trabajaré en ello, pero conseguir un MVP es mi máxima prioridad en este momento.

El Futuro

He empezado a trabajar en la parte central de mi proyecto desde la semana pasada. He empezado en la parte del núcleo, refiriéndome a la implementación de shaders para ser renderizados. Eso supuso avanzar en el tema de librerías, en concreto en DirectX 11.

El último problema que al que me enfrenté tenía que ver con el hecho de que todos los shader de libretro que pensaba que se compilarían fácilmente con OpenGL...no lo hicieron.

Sin entrar en demasiados detalles, estos shaders fueron escritos en un lenguaje de sombreado ligeramente diferente (Cg) que el que utiliza D3D (HLSL).

Probablemente podría terminar el backend e implementar un montón de shaders preestablecidos para que los usuarios lo usen, pero no quería que todos los shaders estuvieran "preestablecidos" sobre todo teniendo en cuenta el esfuerzo que he puesto en el proyecto.

Así que, envié un correo electrónico al desarrollador principal de libretro y charlamos un rato, luego me invitó a su canal de IRC y llegamos a las siguientes conclusiones:

- Ambos proyectos se beneficiarían enormemente al portar estos shaders a Direct3D. Cg está ya en desuso y los desarrolladores de Libretro querrían deshacerse de éste y pasarse a D3D.

- Hay alrededor de 600 shaders que necesitan portar, que se utilizan en combinaciones diferentes en más de 500 presets de shader. Eso es un montón de trabajo para mí para hacer en un mes, además de que también tengo que hacer (recordemos) el backend para D3D y OGL. Así que, accedieron a ayudar con el portado de los shaders. Esto sólo podría aumentar la popularidad de libretro después de todo, por lo que ambos proyectos se benefician.

- En el backend, estoy haciendo un progreso rápido, pero es un montón de trabajo, así que no estoy seguro de cuanto tiempo me llevará todo, sobre todo porque, como he mencionado, D3D11 y OpenGL (ES) requieren implementaciones diferentes.

- Afortunadamente muchos shaders no utilizan características muy avanzadas de la especificación, por lo que serán compatibles. Por supuesto, intentaré poner en práctica todo lo que pueda -si no todo-, para hacer uso de tantos shaders preexistentes como sea posible.

Si no me enfrentara a tantos problemas inesperados (y no hubiera perdido casi un mes debido a los exámenes) las cosas podrían haber sido diferentes, pero ¿qué puedes hacer? estas cosas pasan en el mundo de la programación

En definitiva, tengo esperanzas puestas en agosto. No hay duda de que será muy intenso ya que es el tramo final... ¡pero estoy listo para darle caña!

Fuente original: https://kodi.tv/article/gsoc-2017-update-shader-support
LEER MÁS
Imagen


Hacía tiempo que queríamos realizar esta guía; tras varios días de trabajo ya la tenemos lista y terminada. El sistema funciona realmente bien.

La idea de este tutorial es la de conseguir poder reiniciar nuestro NAS con Xpenology a Windows 10 (y/o a otros sistemas) desde el propio sistema de Xpenology (DSM) de forma automática y sin problemas, dándole click a una app que encontraremos en Centro de Paquetes o incluso con una app de nuestro móvil. ¿Es tan fácil? ¡Si!

¿Para qué es interesante poder cargar un Windows nativo? Pues principalmente para los juegos, poder jugar de forma nativa con nuestro NAS o incluso mediante Streaming. Una vez apagado o reniciado el NAS con Windows, automáticamente cargará siempre DSM.

Os recordamos que esta guía no se encuentra en ningún lugar de la red, no hay información sobre este método ni en inglés ni en ruso, ni en chino. Es elaboración propia tras varios días de duro trabajo, así que aprovechadla a tope.

Podéis consultar la guía en el siguiente link: viewtopic.php?f=21&p=80139&sid=f686f1565b104b2161a39e87541d2eca#p80139
LEER MÁS