# Cambiar tiempo avance en Kaffeine, 20s es mucho(solv)

## elchicosinhada

Pues soy aficionado al anime subtitulado y muchas veces no termino de leer algún sub así que pulso izquierda para retroceder, pero retrocede 20s y claro, tengo que volver a ver esos 20s para leer el fragmento de los últimos 3...

Supongo que habrá que modificarlo en xine-lib, pero no encuentro la opción, ni siquiera se si existe...

Alguien sabe si se puede y en el caso de poder, como?Last edited by elchicosinhada on Thu Mar 20, 2008 10:53 am; edited 1 time in total

----------

## mad93

Tengo el mismo 'problema' y por eso precisamente (que al final es por comodidad) uso mplayer.

----------

## i92guboj

En un vistazo rápido veo que el valor está grabado a fuego en el código fuente del programa. Tras un par de greps llegué a esto:

```

# grep -r slotJumpIncrement *

kaffeine/src/player-parts/xine-part/xine_part.cpp:      slotJumpIncrement( 20 );

kaffeine/src/player-parts/xine-part/xine_part.cpp:      slotJumpIncrement( -20 );

kaffeine/src/player-parts/xine-part/xine_part.cpp:      slotJumpIncrement( 60 );

kaffeine/src/player-parts/xine-part/xine_part.cpp:      slotJumpIncrement( -60 );

kaffeine/src/player-parts/xine-part/xine_part.cpp:      slotJumpIncrement( 600 );

kaffeine/src/player-parts/xine-part/xine_part.cpp:      slotJumpIncrement( -600 );

kaffeine/src/player-parts/xine-part/xine_part.cpp:void XinePart::slotJumpIncrement(int increment)

kaffeine/src/player-parts/xine-part/xine_part.h:        void slotJumpIncrement(int);

```

No es dífícil de parchear. Luego tan solo queda hacer un diff con el original, copiar el ebuild de kaffeine seleccionado a nuestro overlay, e incluir el parche en dicho ebuild. En un googleo rápido, he encontrado un parche para hacer esos tiempos algo más configurables mediante menus, pero parece ser para 0.5, por lo que dudo que funcione. Kaffeine ha cambiado muchísimo desde entonces.

http://www.nabble.com/Patch----Configure-Position-Skip-td13492783.html

----------

## elchicosinhada

Aqui hay uno para la 0.85. Es de los mismos pero esta mucho más actualizado el parche. Supongo que este si funcionaria

Parche

Pero no se ni como aplicarlos ni nada xD

----------

## i92guboj

 *elchicosinhada wrote:*   

> Aqui hay uno para la 0.85. Es de los mismos pero esta mucho más actualizado el parche. Supongo que este si funcionaria
> 
> Parche
> 
> Pero no se ni como aplicarlos ni nada xD

 

Puedo hacerte un ebuild que lo aplique, pero no ahora mismo. Quizás esta tarde, o mañana, o el domingo... cuando tenga media horita para ponerme (contando con que el parche ande y no tenga que retocarlo, no lo he mirado). Si no tienes prisa, para el lunes está seguro, puede que antes, pero no prometo nada  :Razz: 

Si alguien quiere ponerse, es tan solo añadir una línea con epatch al ebuild y poner el parche en el dir files/ del ebuild. Algo como:

```

epatch "${FILESDIR}/nombreparche.patch"

```

En la función src_unpack() del ebuild.

----------

## elchicosinhada

Gracias  :Very Happy: 

Probaré a hacerlo yo, aunque a saber que hago xD

----------

## achaw

```
# Copyright 1999-2007 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/media-video/kaffeine/kaffeine-0.8.5.ebuild,v 1.7 2007/10/08 18:11:47 drac Exp $

inherit eutils kde flag-o-matic autotools

DESCRIPTION="Media player for KDE using xine and gstreamer backends."

HOMEPAGE="http://kaffeine.sourceforge.net/"

SRC_URI="mirror://sourceforge/kaffeine/${P}.tar.bz2"

LICENSE="GPL-2"

SLOT="0"

KEYWORDS="amd64 ppc ppc64 sparc x86 ~x86-fbsd"

IUSE="dvb gstreamer xinerama vorbis encode kdehiddenvisibility xcb"

RDEPEND=">=media-libs/xine-lib-1

   xcb? ( >=x11-libs/libxcb-1.0

      >=media-libs/xine-lib-1.1.5 )

   gstreamer? ( =media-libs/gstreamer-0.10*

      =media-plugins/gst-plugins-xvideo-0.10* )

   media-sound/cdparanoia

   encode? ( media-sound/lame )

   vorbis? ( media-libs/libvorbis )

   x11-libs/libXtst"

DEPEND="${RDEPEND}

   dvb? ( media-tv/linuxtv-dvb-headers )"

need-kde 3.5.4

pkg_setup() {

   if use xcb && ! built_with_use --missing false media-libs/xine-lib xcb; then

      eerror "To enable the xcb useflag on this package you need"

      eerror "the useflag xcb enabled on media-libs/xine-lib."

      eerror "Please emerge media-libs/xine-lib again with the xcb useflag"

      eerror "enabled."

      die "Missing xcb useflag on media-libs/xine-lib."

   fi

}

src_unpack() {

   kde_src_unpack

   cd "${S}"

   # allow $(with_xcb)

   epatch "${FILESDIR}"/kaffeine-with-xcb.patch

    epatch "${FILESDIR}/nombreparche.patch" 

   eautoconf

}

src_compile() {

   # see bug #143168

   replace-flags -O3 -O2

   local myconf="${myconf}

      $(use_with xinerama)

      $(use_with dvb)

      $(use_with gstreamer)

      $(use_with vorbis oggvorbis)

      $(use_with xcb)

      $(use_with encode lame)"

   kde_src_compile

}

src_install() {

   kde_src_install

   # Remove this, as kdelibs 3.5.4 provides it

   rm -f "${D}"/usr/share/mimelnk/application/x-mplayer2.desktop

}
```

Algo asi, donde nombreparche.patch, obviamente el el normbre del parche  :Smile: 

No te olvides de poner el parche en el dir files/ del ebuild como dice i92guboj

Saludos

----------

## elchicosinhada

Pues no me va, me da errores al aplicar el parche.

----------

## i92guboj

Ese parche, en contra de lo que diga en el foro de kaffeine, no anda contra la estable de kaffeine. No aplica limpiamente, si bien limpiarlo debería ser trivial, la mayoría de los fallos a primera vista son por cosas simples en xine_part.[ch]. En un ratito si puedo postearé algo.

EDITADO: ahí va un enlace a un overlay que contiene el parche, y los ebuilds modificados para todas las versiones que tengo en mi portage ahora mismo. Tan solo descomprímelo en el directorio de tu overlay local y debería funcionar.

http://jesgue.homelinux.org/ebuilds/kaffeine.tar.bz2

NOTAS FINALES:

1.- El parche no es mío, aunque si que he tenido que hacer modificaciones.

2.- Borrad $HOME/.kde/share/apps/kaffeine/xine_part.rc, porque si está presente, toma precedencia y por tanto la nueva opción de menú no aparece

Una vez que hayais hecho esto, iniciad kaffeine, y habrá una opción nueva en el menú navigation. También saldrá el diálogo pulsando control+fin.

----------

## elchicosinhada

Bueno, el parche se aplica perfectamente y el menú aparece, Gracias tio  :Very Happy: 

El problema es que no funciona correctamente, es como si los saltos estubiesen programados a unos segundos específicos, y si intentas avanzar varias veces seguidas se no avanza, si no que vuelve al segundo que había quedado en el salto anterior.

Miraré un poco el parche a ver si lo termino de entender, que C++ si, pero QT nada de nada... y ver como hacen los saltos para intentar corregirlo o algo.

Por otro lado, no sé si os pasa a vosotros, pero no se guarda la configuración y se vuelve a poner a 20s.

----------

## i92guboj

Es de esperar que este parche cause problemas, porque al parecer está rodando por ahí desde hace unos años, y no ha sido aún incluído en el svn oficial de kaffeine. Desde la versión 0.5 que es para la que fue diseñado han pasado unos añitos. Ni siquiera he probado las funcionalidades del parche, tan solo he comprobado que la opción estaba presente.

No he mirado el parche en profundidad quizás lo haga si tengo un rato, pero no estoy seguro de si eso será lo mejor. Quizás convenga más rediseñar algo desde nuevo pero para eso lo mejor sería entrar en contacto con el equipo de desarrollo de kaffeine antes de hacer nada, y seguir su guía para que esto entre en la rama oficial si es que eso es posible.

----------

## elchicosinhada

Vale, lo he revisado, y el parche y parece todo correcto asi que para mi que falla por cosas de xine...

----------

## i92guboj

 *elchicosinhada wrote:*   

> Vale, lo he revisado, y el parche y parece todo correcto asi que para mi que falla por cosas de xine...

 

Creo que se a lo que te refieres. A veces ocurre que al pulsar sobre la barra, o ir hacia adelante de cualquier otro modo, el stream se queda como bloqueado en un punto, al que vuelve siempre. Esto me ocurre en gxine también, en kaffeine, codeine y un largo etc de players basados en xine, así que si, supongo que es cosa del motor de xine. También es verdad que no ocurre en todos los tipos de streams. Como xine puede usar una gran cantidad de decodificadores externos, puede que el problema sea con algunos de ellos. En cualquier caso, es algo de bastante bajo nivel ya que posiblemente tenga también algo que ver en como los distintos codecs interactúan (recordemos que un fichero de medios puede contener un número indeterminado de streams, cada uno usando un codec distinto). Esto no facilita la tarea para nada.

He probado un poco más y todo parece funcionar, excepto por eso. Pero ese problema ya estaba antes, y es fácilmente reproducible en cualquier reproductor basado en xine. Lo que si es algo molesto es lo de que no guarde los valores entre sesiones  :Razz: 

----------

## Inodoro_Pereyra

Perdón si digo una burrada pero segun tenía entendido, todos los archivos de video tienen ¿keys es el nombre? cada X cantidad de tiempo, (al menos los que siguen la estructura AVI), configurable a gusto del que lo codificó con tal o cual codec y normalmente los que hacen las teclas o botones que controlan las funciones adelantar y atrasar de los reproductores es saltar de ¿key? en ¿key?...

Si el que codificó el video, puso los ¿keys? muy separados, entonces a menos que avances o retrocedas a mano, desde algun control deslizable o similar los saltos van a ser siempre de la misma "distancia".

Salud!

----------

## i92guboj

 *Inodoro_Pereyra wrote:*   

> Perdón si digo una burrada pero segun tenía entendido, todos los archivos de video tienen ¿keys es el nombre? cada X cantidad de tiempo, (al menos los que siguen la estructura AVI), configurable a gusto del que lo codificó con tal o cual codec y normalmente los que hacen las teclas o botones que controlan las funciones adelantar y atrasar de los reproductores es saltar de ¿key? en ¿key?...
> 
> Si el que codificó el video, puso los ¿keys? muy separados, entonces a menos que avances o retrocedas a mano, desde algun control deslizable o similar los saltos van a ser siempre de la misma "distancia".
> 
> Salud!

 

Bueno, eso depende del software. En xine o en mplayer teóricamente te puedes mover a donde quieras. Sin embargo, a veces los algoritmos de interpolado fallan, aunque tampoco estoy seguro de que el problema con el posicionado en xine esté estrictamente relacionado con esto...

El palabro "keyframe" viene de la animación clásica. Cuando se creaba una animación a mano se creaban una serie de bocetos que eran los que definían la animación. Éstos eran creados por el animador jefe normalmente. Luego los espacios entre esos momentos clave eran llenados hasta completas los 24 cuadros por segundo por el resto del equipo de animadores.

En el mundo de los formatos de video comprimido el término viene a significar algo muy parecido (solo que el espacio entre keyframes lo rellena el software, de una o múltiples formas). Verás, los archivos de video comprimido no almacenan todos los frames, sino que almacenan solo las variaciones de un frame al siguiente, con lo cual se ahorra mucho espacio. Sin embargo el método tiene un problema: siguiendo esa lógica, si queremos ver los 10 últimos segundos de la peli, tendriamos que empezar por el principio, y calcular el frame que está a 10 segundos del final aplicando todos los cambios desde el primer frame de la películo (lo cual computacionalmente es inviable).

Lo que se hace en lugar de eso es usar keyframes, que funcionan a modo de torretas de la luz, indicadores, boyas o como queramos llamarlos (o más bien como repetidores de radio o tv  :Razz:  ). Los keyframes se almacenan completos, y si tenemos un keyframe en -digamos- 0:00:30.0, y queremos ver el frame justo en 0:00:30.10 solo tenemos que coger el keyframe en 30, aplicarle los cambios hasta 30.10 y ya lo tenemos. Así nos ahorramos el tener que aplicar todos los cambios desde el primer frame.

Los métodos de interpolación de hoy día y el hardware actual permiten hacer esto en tiempo real, por lo que en principio, y siempre que los métodos de interpolación funcionen y el hardware acompañe, no debería haber problema en calcular cualquier frame (siempre que los keyframes no estén rotos, cosa que a veces puede pasar en torrents, amules, discos comprimidos con codecs no muy sanos.... etc etc).

----------

## sefirotsama

[OT] i92guboj, ¿eres devoloper? solo por curiosidad 

¿como has aprendido lo de tocar los ebuild y tal?, o ¿Cómo sabias como encontrar la parte de codigo dónde está asignado el tiempo de "salto"?[/OT]

----------

## i92guboj

 *sefirotsama wrote:*   

> [OT] i92guboj, ¿eres devoloper? solo por curiosidad 
> 
> ¿como has aprendido lo de tocar los ebuild y tal?, o ¿Cómo sabias como encontrar la parte de codigo dónde está asignado el tiempo de "salto"?[/OT]

 

Soy informático de carrera aunque no ejerzo como programador en mi trabajo (normalmente, más que nada por falta de tiempo). Colaboro en algunos proyectos en la medida que mi tiempo me lo permite, que no es mucho, para intentar no oxidarme.

Los ebuilds en si no son más que scripts de bash, y tampoco soy un maestro en el tema... solo hago ebuilds a nivel básico, aunque todo es ponerse jeje. Se empieza modificando los que ya están en portage, luego los clonas para adaptarlos a otras aplicaciones que tengan un proceso de desempaquetado y compilación similar. Y poco a poco mirando, preguntando, viendo y cambiando cosas algo se te queda. Nunca me he puesto en serio con el tema de los ebuilds... lo que pasa es que llevo aquí para 5 añitos ya  :Razz: 

En cuanto a la búsqueda en el código fuente, en realidad es bastante simple. Descargas el tarball de kaffeine, lo descomprimes donde quieras, y le haces un "grep -r palabra *", si cambias palabra por "skip", "Skip" o "20" que es su valor predeterminado pues vas buscando y encontrando referencias que te dicen en qué ficheros está la cosa más o menos. 

A partir de ahí, tienes que conocer el lenguaje de programación para que al ver las partes del fichero que grep te da entiendas lo que están haciendo, y por donde seguir mirando. Si hay algo bueno en qt, es que los programas basados en qt y kdelibs son ridículamente simples, incluso abarcando funcionalidades muy diversas. Es lo bueno de la reutilización de código y la programación orientada a objetos, aunque a muchos eso parezca pesarles  :Razz: 

----------

## Inodoro_Pereyra

Espectacular la explicación de los keyframes, hay que reconocer! Ahora me quedó clarísimo todo. Gracias...

Salud!

----------

## elchicosinhada

 *i92guboj wrote:*   

> Es lo bueno de la reutilización de código y la programación orientada a objetos, aunque a muchos eso parezca pesarles 

 

Que haría yo si la orientación a objetos y la reutilización de código, de hecho, uso la Herencia en todo lo que puedo y más  :Very Happy: 

----------

