RootDev@blog:~$

¿Quién no se ha encontrado alguna vez con una web cuyo vídeo embebido nos gustaría descargar pero, o bien no tenemos herramientas, o bien esas herramientas no soportan el sitio que estamos visitando?

Llevo haciendo esto bastante tiempo, pero nunca me he parado a abrir una entrada, pero ayer mismo tuve que descargarle a una amiga unos vídeos de la web de laSexta y se me planteó que quizá le vaya a resolver el problema a mucha más gente… que use Linux, claro. Que además es un problema demasiado común, y que se puede arreglar de una forma bastante interesante, sin necesidad de usar plug-ins y recurriendo a las capacidades que el directorio /proc nos ofrece.

Sí, sí, a ese endemoniado directorio volátil donde las carpetas aparecen y desaparecen a placer vamos a sacarle por fin una utilidad práctica al usuario medio. Inconvenientes: lo que vamos a hacer ahora vamos a hacerlo todo por consola. ¿Por qué? Bueno, se podría hacer por entorno gráfico, pero es que como no todo el mundo usa Gnome, ni todo el mundo usa KDE, ni tampoco hay entendimiento entre los usuarios que usan cada uno de los infinitos entornos gráficos disponibles para GNU/Linux, pues la única forma general de hacer esto es dejándonos las manos. ¿No es maravilloso?

¿Cómo empezamos? Lo primero es abrir la web donde tengamos el vídeo que queramos bajar y dejar que cargue hasta el final. No hace falta reproducirlo, nos interesa que el navegador los descargue en alguna parte secreta del ordenador y echarle mano. ¿Dónde se lo descarga? Quién sabe. Pero de lo que estamos todos seguros es de dos cosas: una, que lo hace en un archivo (no tiene por qué, pero ya veremos que es así en prácticamente todos los casos) y dos, que ese archivo ha de estar abierto por el navegador para poder reproducirse.

Dicho sea esto, ¿cómo hacemos para destripar al navegador en ejecución y saber qué archivos tiene abiertos? Esto depende del navegador, pero el procedimiento es en general es el mismo. De todas formas, voy a hacerlo con dos navegadores (firefox y opera) que son los que tengo instalados, los que uso, y que me sirven para ejemplificar dos casos distintos, abriendo la mente para poder aplicarlo a otros casos.

En cualquier caso, todo programa en ejecución en Linux tiene un subdirectorio en el directorio /proc. Estos directorios son números, que se corresponden con el PID (el id de proceso, un número que identifica cada programa en memoria). Dentro de esos subdirectorios hay algunos archivos y subdirectorios más, con información de fallos de página, programa que le es padre, información de memoria, tiempo en ejecución, mapeos, directorio en curso y… oh, sí, archivos abiertos. Supongamos un programa con el PID 4421. Su directorio asociado sería /proc/4421. Dentro de ese, habría un subdirectorio más, llamado /proc/4421/fd, en el cual hay enlaces simbólicos a cada archivo abierto, pero con los nombres cambiados, como números. Estos números se corresponden con el descriptor de archivo abierto, un número que identifica eso, cada archivo abierto por un programa. Serán archivos como /proc/4421/fd/0, /proc/4421/fd/1, /proc/4421/fd/2, /proc/4421/fd/10… Ojo: esto no son los archivos per-se, son sólo enlaces simbólicos a sus rutas reales. Hay que tenerlo en cuenta para lo que vamos a hacer.

Ahora, claro, ¿cuál de esos numeritos se corresponde con el archivo abierto? ¿Y cuál es el PID del navegador? ¿Y cómo hacemos? Pues como dije antes, depende. Empecemos por el caso más corriente:

En Firefox
El primer paso es detectar el PID del proceso del navegador. El programa es firefox-bin (ojo con esto), así que ejecutamos lo siguiente:

$ ps x | grep firefox-bin

Y nos saldrá una lista parecida a esta:

$ ps x | grep firefox-bin
5770 ? S 0:00 /bin/sh /usr/lib/firefox/run-mozilla.sh /usr/lib/firefox/firefox-bin
5775 ? Sl 35:44 /usr/lib/firefox/firefox-bin
9211 pts/1 S+ 0:00 grep firefox-bin

Señalo en negrita el proceso que corresponde. ¿Cómo identificarlo? Bueno, tiene que ser el que más tiempo lleva en funcionamiento (35:44), y sobre todo, ser un programa a secas. La anterior es un comando que llama a la shell para llamar a run-mozilla.sh para abrir firefox-bin. Se detecta fácilmente por los espacios en el nombre del comando. Ese no es. Y el otro, el de grep, es lo que estamos usando para cribar la lista de procesos en busca del firefox. ¿Cuál es el PID entonces? Es el primer número empezando por la izquierda, el 5775.

Ya tenemos el PID. Ahora cambiamos hábilmente de directorio con:

$ cd /proc/5775/fd

Y estaremos en la carpetita donde se abren todos los archivos. Uuuhm. ¿Cuál de ellos será? Tendremos que abrirlos uno a uno y probar

En serio, no es complicado, y se reduce a un sólo comando:

$ file -L *

Esto nos permitirá indagar en el interior de los archivos abiertos (siguiendo los enlaces, opción -L) y averiguar qué leches son. Deberíamos ver una lista más o menos como esta:

$ file -L *
0: character special
1: ISO-8859 English text, with CRLF, LF line terminators, with escape sequences
10: fifo (named pipe)
11: socket
12: socket
13: socket
14: socket
15: empty
16: character special
17: fifo (named pipe)
18: socket
19: fifo (named pipe)
2: ISO-8859 English text, with CRLF, LF line terminators, with escape sequences
20: socket
21: socket
22: socket
24: Zip archive data, at least v2.0 to extract
25: directory
26: Zip archive data, at least v1.0 to extract
27: fifo (named pipe)
28: fifo (named pipe)
29: Zip archive data, at least v2.0 to extract
3: socket
30: socket
31: socket
32: socket
33: Zip archive data, at least v1.0 to extract
34: Zip archive data, at least v1.0 to extract
35: Zip archive data, at least v1.0 to extract
36: SQLite 3.x database, user version 1
37: Zip archive data, at least v1.0 to extract
38: SQLite 3.x database, user version 6
39: SQLite 3.x database, user version 2
4: fifo (named pipe)
40: fifo (named pipe)
41: fifo (named pipe)
42: Berkeley DB 1.85 (Hash, version 2, native byte-order)
43: Berkeley DB 1.85 (Hash, version 2, native byte-order)
44: Zip archive data, at least v1.0 to extract
45: raw G3 data, byte-padded
46: Zip archive data, at least v1.0 to extract
47: Zip archive data, at least v1.0 to extract
48: Zip archive data, at least v1.0 to extract
49: Zip archive data, at least v1.0 to extract
5: socket
50: Zip archive data, at least v2.0 to extract
51: DOS executable (device driver) for DOS
52: DOS executable (device driver) for DOS
53: DOS executable (device driver) for DOS
54: SQLite 3.x database
55: SQLite 3.x database, user version 5
57: SQLite 3.x database
58: Mozilla XUL fastload data
59: data
6: fifo (named pipe)
61: SQLite 3.x database, user version 3
62: SQLite 3.x database, user version 8
63: socket
66: data
69: Macromedia Flash Video
7: fifo (named pipe)
8: fifo (named pipe)
9: fifo (named pipe)

Vemos muchas cosas, pero señalo lo que nos interesa: Macromedia Flash Video (formato de vídeo de Macromedia), en un archivo llamado 69. Esto es lo que usa YouTube a la hora de visualizar vídeos.

¿No nos lo creemos? ¿Por qué no intentamos reproducir ese archivo con nuestro reproductor favorito a ver qué pasa, y comprobar si es ese el archivo que queremos ver? (vlc por ejemplo, elección a cargo del lector)

$ vlc 69

El resultado que obtengo es parecido a este (click para agrandar):

Que efectivamente, es ese el vídeo. Estupendo entonces, cerramos el reproductor, ahora sólo tenemos que copiarlo donde nos plazca con el nombre que nos salga de las narices:

$ cp 69 /home/waldo/Documents/Multimedia/Video/Anime/Popotan-opening.flv

Nótese que le pongo la extensión .flv, la que es propia de este tipo de archivo (Macromedia Flash).

¡Y fin! Sólo decir que el navegador puede haber cargado varios vídeos, o sea que puede llevarnos un tiempo buscar cuál de ellos es el correcto. En mi caso sólo hubo uno, pero pueden salir más y de más tipos (como MPEG) como veremos ahora.

En Opera
Vamos a aplicar el ejemplo sobre la página de laSexta, dejamos que cargue (en mi caso no lo pude saber hasta tragarme el programa completo, no sale esa barrita supérflua de qué porcentaje del vídeo se ha obtenido) y vamos a buscar el PID. El procedimiento no difiere prácticamente en nada con el firefox, salvo en el proceso a buscar:

$ ps x | grep operapluginwrapper
9533 ? RNLl 0:25 /usr/lib/opera/9.63/operapluginwrapper 55 58 /usr/lib/opera/plugins/libflashplayer.so
9581 pts/1 S+ 0:00 grep operapluginwrapper

(Ya que Opera crea un proceso aparte para el plugin de Flash) Nuestro PID es entonces 9533. Como siempre vamos a /proc/9533/fd y allí miramos qué cosa son esos archivos:

$ cd /proc/9533/fd
$ file -L *
$ file -L *
0: fifo (named pipe)
1: ISO-8859 English text, with CRLF, LF line terminators, with escape sequences
10: ISO Media, MPEG v4 system, version 2
11: character special
12: character special
13: character special
16: socket
17: socket
18: socket
2: ISO-8859 English text, with CRLF, LF line terminators, with escape sequences
20: fifo (named pipe)
28: socket
3: socket
33: socket
37: socket
4: Berkeley DB 1.85 (Hash, version 2, native byte-order)
43: socket
46: socket
49: socket
5: Berkeley DB 1.85 (Hash, version 2, native byte-order)
52: socket
54: socket
55: fifo (named pipe)
58: fifo (named pipe)
6: socket
7: empty
8: socket
9: socket

Como siempre marco a los sospechosos. MPEG v4 me suena a que es un vídeo, pues nada, comprobamos que ese archivo (10 en este caso) con el vlc o el xine o el que sea, es nuestro vídeo:

$ vlc 10

Como no podía ser de otra forma, lo es (al fin y al cabo, es el único vídeo):

Y nada, lo copiamos a donde nos plazca:

$ cp 10 /home/waldo/Documents/Multimedia/Video/TV/SQLH-01.mpg

Nótese que esta vez le pongo extensión .mpg (es un archivo MPEG). En Linux esto suele dar bastante igual, pero es bueno elegir bien las extensiones para saber qué clase de archivo es cada uno.

Y así. ¡Fácilmente! Esto se puede usar para prácticamente cualquier programa que esté operando con archivos y no sepamos qué archivos son. Pero una aplicación práctica es esta.

Sí, sí, también funciona con Pornotube, YouPorn y RedTube. Es la hostia.

-----

thz Batch :-)