ITU tiriti TRAN UTRAN treroooo

ITU tiriti TRAN UTRAN treroooo

[Update 18 febrero 2017]

[Update 19 febrero 2017]

ITU tiriti TRAN UTRAN treroooo

ITU (International Telecommunications Union)

UTRAN (Universal Terrestrial Radio Access Network)

UMTS (Universal Mobile Telecommunications System)

Those above are some links to en.wikipedia articles on some telecommunications standards regarding wireless and mobile telephony specifications.

Well… except for the first one, which is a link to a Spanish song that sounds alike with UTRAN, although it is quite a different matter…

(I’ll publish right now and will update because this is going to be a long post I’ll be writing for some hours and then I’ll translate some paragraphs, at least with Google Translator with the copy and paste dangerous method (that picks randomly some times, finding curious  things like ‘Vt’, translated as. “Vermont”, not in a geographical but, in a grammar context, which should be ‘Vt’.  “Verb transitive”).  [ 😀 ]).

Some useful ffmpeg, FourCC, telephony and other oddities concepts.

(Coming soon!).

[Unfortunately… I run out of tobacco, so I will update later, but first I’ll give some useful links I’ll comment afterwards, regarding ffmpeg comand line tool, Apple, Quicktime, moov atoms, headers, muxing, demuxing…]

http://www.adobe.com/devnet/video/articles/mp4_movie_atom.html

https://wiki.multimedia.cx/index.php?title=QuickTime_container#edts

https://wiki.multimedia.cx/index.php?title=QuickTime_container

https://wiki.multimedia.cx/index.php/PCM#Logarithmic_PCM

https://wiki.multimedia.cx/index.php/8BPS

https://wiki.multimedia.cx/index.php?title=QuickTime_container#Known_FOURCCs

ASCII codes in decimal and hexadecimal notation:

a         97       decimal          61 hexadecimal
b         98      decimal          62
c         99                                 63
d        100
e        101
f         102
g        103
h        104                                68
i         105
j         106
k        107
l         108                                                                     ltr           rtl len=2           rtl
m      109                                 6D             ‘ms’    (6D73 ||    736D        ||      37D6)
n        110                                 6E
o         111                                  6F
p         112                                 70
q         113                                 71
r          114
s          115                                 73
t          116
u         117
v          118
w         119
x          120                                78
y          121
z          122                                 7A
———————-
WATCHOUT!!!!!!!
———————-

@ 64

A        65                                    41

K        75                                    4B

P        80

S         83

U        85                                    55

Z         90                                   5A

———————-
0          48
1           49
2          50

8           56

FourCC 8BPS                            [56 66 80 83]
9            57

(fn)[Alt]+(numPad)

https://ffmpeg.org/ffmpeg-all.html

Update 18 febrero 2017

I’ll go on with this now I got tobacco enough for the next twenty-something hours…

Let’s start with the end!

(Graciously borrowed from en.wikipedia, the free encyclopedia).

[I’ll go on translating and commenting this paragraph and the rest of the post into Spanish]

Examples[edit]

For example, suppose we have the following linked list data structure:

struct node {
        int data;
        struct node *next;
};

We can easily create a linked list data structure in memory using such an object, but when we attempt to save it to disk we run into trouble. Directly saving the pointer values won’t work on most architectures, because the nodes will almost certainly be loaded into different memory positions. One way of dealing with this is to assign a unique id number to each node and then unswizzle the pointers by turning them into a field indicating the id number of the next node:

struct node_saved {
        int data;
        int id_number;
        int id_number_of_next_node;
};

We can save these records to disk in any order, and no information will be lost. Other options include saving the file offset of the next node or a number indicating its position in the sequence of saved records.

When we go to load these nodes, however, we quickly discover that attempting to find a node based on its number is cumbersome and inefficient. We’d like our original data structure back so we can simply follow next pointers to traverse the list. To do this, we perform pointer swizzling, finding the address of each node and turning the id_number_of_next_node fields back into direct pointers to the right node.

(Pure publishing-updating while writing live posting style, beware of changes and mistakes).

( Cuidado con los cambios y errores, estilo puro de publicación-actualización mientras escribo).

For example, suppose we have the following linked list data structure:

Supongamos por ejemplo que tenemos la siguente estructura de datos en una lista enlazada:

struct node {
int data;
struct node *next;
};

We can easily create a linked list data structure in memory using such an object, but when we attempt to save it to disk we run into trouble. Directly saving the pointer values won’t work on most architectures, because the nodes will almost certainly be loaded into different memory positions. One way of dealing with this is to assign a unique id number to each node and then unswizzle [2] the pointers by turning them into a field indicating the id number of the next node:

Se puede crear fácilmente una estructura de datos de lista enlazada en memoria utilizando un objeto como este, pero cuando queremos guardarlo en el disco duro no nos deja. Guardar directamente los valores del puntero no funcionará en la mayoría de arquitecturas porque los nodos [1] de la lista enlazada estarán situados en posiciones de memoria [en celdillas de almacenamiento fijas o volátiles] distintas.

[1  Generalmente los archivos en un ordenador no se representan ni se guardan en un solo bloque de datos seguido, como se guardarían los datos de una canción en un disco de vinilo, por ejemplo, sino que se almacenan en porciones que van de un lado a otro en la superficie del soporte de almacenamiento, en un giradiscos de vinilo, el brazo de la aguja se volvería loco saltando hacia adentro y hacia afuera, o si fuese seguido sonarían trozos de canciones diferentes. Un ordenador no almacena los datos de forma secuencial, sino que los va repartiendo, por eso se necesita un índice que te va diciendo de dónde a dónde se tiene que leer para reconstruir el archivo. La lista enlazada (o doblemente enlazada) almacena en cada trozo de archivo (==nodo) la dirección al trozo (== nodo) siguiente ( *next)].

Una forma de resolver ese problema es asignarle a cada nodo un identificador único, un número de ID, y después “demezclar” [2] los punteros transformándolos en un campo que indica el número de ID del nodo siguiente.

[2 Un puntero apunta a una dirección de memoria en que los datos se encuentran, de la misma forma que un domicilio apunta a una vivienda donde se encuentra un ocupante. Para acceder a los datos en esa dirección se llama la ubicación contenida en el puntero. En C y C++ se antepone un asterisco para indicar que el dato no es un valor sino (el puntero) la dirección donde el valor se encuentra. Para acceder al valor indicado por el puntero se derreferencia. Pero en este caso además los punteros van entremezclados. En inglés la palabra es ‘swizzel’ : “agitador, mezclador”, así que ‘unswizzle’, lo he llamado “demezclar”, y lo que hace es ordenar correctamente los datos indicados, en este caso por la ID de cada nodo].

struct node_saved {
int data;
int id_number;
int id_number_of_next_node;
};

We can save these records to disk in any order, and no information will be lost. Other options include saving the file offset of the next node or a number indicating its position in the sequence of saved records.

Se pueden grabar estos registros en el disco en cualquier orden, y no se perderá información. Otras opciones incluyen guardar el desplazamiento [3] del nodo siguiente o la posición [4] en la secuencia de registros guardados.

[3  Los soportes de almacenamiento digital: disco duro, memoria RAM, memoria flash, USB… tienen una tabla con las direcciones físicas absolutas a cada celdilla donde la información se va guardando (o leyendo). Los archivos tienen un inicio y un final. El inicio del archivo en valor relativo es cero ‘0’, en valor absoluto ese ‘0’ no suele coincidir con la primera posición que recorre el cursor (la aguja del brazo del giradiscos) en el disco duro (etc…). Además dentro de lo que es el archivo en sí y respecto a esa posición ‘0’, el primer trozo de archivo ocupa una “longitud” que es su tamaño, de forma secuencial el siguiente trozo de archivo estaría en la posición ‘0’+”tamaño”+terminación de trozo+tamaño dirección siguiente. Pero la dirección generalmente no es la que resultaría de ese cálculo, sino que tiene lo que se llama “desplazamiento” ‘shift’ en inglés].

[4  En realidad la posición, técnicamente no estaría en ‘0’, sinó en ‘0’+1. Esto es así porque hay dos conceptos básicos en programación:

int ind;

int pos;

‘ind’ se usa para indicar un “índice”.

‘pos’, se usa para indicar una  “posición”.

De la misma forma que cuando miramos en un libro el índice para encontrar la página en que está el capítulo que queremos leer, ese capítulo no está en el índice, el principio de archivo no está en el índice, sino en la posición, y dependiendo de cómo esté escrito el código se usa uno u otra].

[… Hay programadores profesionales que esto no lo tienen claro… aunque parezca increíble…].

😀

When we go to load these nodes, however, we quickly discover that attempting to find a node based on its number is cumbersome and inefficient. We’d like our original data structure back so we can simply follow next pointers to traverse the list. To do this, we perform pointer swizzling [5], finding the address of each node and turning the id_number_of_next_node fields back into direct pointers to the right node.

Cuando se cargan esos nodos, sin embargo, se descubre que intentar encontrar un nodo basándose en su número de ID es trabajoso e ineficiente. Nos gustaría tener nuestra estructura de datos original para poder recorrerla simplemente siguiendo la dirección al nodo siguiente de la lista. Para hacer esto debemos “demezclar” los punteros, encontrar la dirección de cada nodo y cambiar el campo “número_de_ID_del_nodo_siguiente” a punteros que apunten a la dirección correcta.

[5 I’ve found a typo! 🙂

Aunque dice ‘swizzel’ debería decir ‘unswizzle’. El ‘swizzel’ se hace al guardar (grabar||escribir) los datos, el ‘unswizzel’ se hace al recuperar (leer) los datos.

Además de esto una lista enlazada puede ser doblemente enlazada, esto es que además de la dirección al nodo siguiente contiene también la dirección al nodo anterior:

struct node {
int data;
struct node *next;
//With double linked lists \’||’ Con listas doblemente enlazadas
struct node *previous;
};

Y finalemnte en cuanto a programación en compilador, hay también punteros dobles (**valor)

Un doble puntero es la dirección a una dirección que apunta donde el valor se encuentra, y hay que derreferenciar dos veces en ese caso.

Resumiendo:

lista enlazada simple: *next

lista doblemente  enlazada: *next, *previous

E indistintamente pueden contener punteros o dobles punteros siendo esto independiente de si la lista es simple o doble.

Después, ‘swizzle’ “mezclado”.

Todo eso (y más cosas) se hace para complicar el acceso a determinadas estructuras de almacenamiento de datos.

Las diferentes arquitecturas de los dispositivos están directamente relacionadas con el hardware y el sistema operativo. 32 ó 64 [watchout!!] bits, Apple, Windows, Android, versiones de estos, y programas.

En cualquiera de esos casos otro concepto básico importante:

Las memorias, en general son almacenes de datos, y pueden ser fijas o volátiles. En ellas el orden de la ristra de ceros y unos en código binario se escriben y leen en orden inverso a como se escriben y leen en el procesador, por eso en ensamblador se usa la notación inversa polaca RPN (Reversed Polish Notation), que es una forma de escribir y leer en orden inverso y es más rápido que el orden human-readable, que es el de las memorias.

Por tanto los datos en los registros del procesador se escriben “reflejados” a como van en las memorias.

Precisamente por eso, en aplicaciones para dispositivos móviles también se escriben como en el procesador, ya que así se consumen menos recursos.

Y aquí paso a la parte de telefonía… (iPhone… curiosamente… ya que yo no tengo ni tuve nunca jamás de los jamases un iPhone…).

La portabilidad e interoperabilidad hacen que se utilicen virtualizaciones de hardware mediante el uso de software. Es lo que se llaman máquinas virtuales. En general las va instanciando y borrando el sistema operativo o la aplicación que las crea, aunque también se pueden crear instancias no-volátiles con programas como DOS-Box o VirtualBox, o Vmware, por ejemplo.

En el caso de las que crea el sistema operativo o la aplicación, se guardan en la carpeta TMP, o TEMP, u otras dependiendo de dónde hayamos puesto la ruta a los datos de aplicación o la variable de entorno correspondiente al instalar.

Se pueden recuperar la mayoría de estos archivos volátiles de trabajo de aplicaciones y sistemas que se guardan en Windows en la carpeta “TEMP”, de ‘temporary’, puesto que no se suelen borrar explícitamente, y menos en telefonía y aplicaciones para dispositivos móviles.

(Voy a pegar aquí los enlaces de arriba referentes a ffmpeg, ya que los otros son referidos a telecomunicaciones y ya he escrito sobre ese tema, si acaso lo explicare en el siguiente post).

[Unfortunately… I run out of tobacco, so I will update later, but first I’ll give some useful links I’ll comment afterwards, regarding ffmpeg comand line tool, Apple, Quicktime, moov atoms, headers, muxing, demuxing…]

http://www.adobe.com/devnet/video/articles/mp4_movie_atom.html

https://wiki.multimedia.cx/index.php?title=QuickTime_container#edts

https://wiki.multimedia.cx/index.php?title=QuickTime_container

https://wiki.multimedia.cx/index.php/PCM#Logarithmic_PCM

https://wiki.multimedia.cx/index.php/8BPS

https://wiki.multimedia.cx/index.php?title=QuickTime_container#Known_FOURCCs

[Desgraciadamente… me he quedado sin tabaco, así que actualizaré más tarde, pero antes daré algunos enlaces útiles que comentaré después, respecto a la herramienta por línea de comando ffmpeg, Apple, Quicktime, moov atoms, cabeceras, muxing, demuxing…].

El primer enlace es a un artículo publicado en la página de Adobe. Los programas Adobe no son opensource, son de código propietario. Aplicaciones como Photoshop, para la edición de imagen, o Adobe Flash Player para vídeo son de Adobe.

En cuanto a archivos de vídeo, en esa página de Adobe viene la definición de un tipo de metadato: ‘moov atom’.

En un archivo cualquiera hay una parte que es la cabecera del archivo ‘header’.

En esa cabecera van informaciones relativas al archivo y sus características. Debido a la forma en que un ordenador lee y escribe, apareció el concepto ‘atom’, como una unidad de información suficiente por si misma para definir los datos que contiene.

An atom is a self-contained data unit that contains information about the video file. The moov atom, also referred to as the movie atom, defines the timescale [6], duration, display characteristics of the movie, as well as subatoms containing information for each track in the movie. The optimal location of the moov atom depends on the selected delivery method.

[6 aunque dice ‘timescale’ en realidad debería decir ‘timestamp’, “marca de tiempo” de archivo, supongo que ‘-ts’ que es como se llama en ffmpeg da lugar a confusión…]

‘moov atom’ es una parte de la cabecera de archivos de vídeo para Apple y Quicktime (en otros sistemas se les llama de otra forma), que define y contiene los datos relativos a la duración, y la fecha, además de las características de resolución de pantalla, y direcciones a otros subátomos (*subatom) que contienen información de cada pista (hilo) que conforma el vídeo: audio, imagen, efectos:-rotation, -blur, -hlflip, -vflip…,  tiempo de inicio,  tiempo de finalización, velocidad de muestreo…

Dependiendo de cómo se vaya a suministrar el vídeo el moov atom con los metadatos puede colocarse antes, después o suministrarse sobre la marcha según se va reproduciendo (que es el caso del ‘streaming’, y es por lo que YouTube [que paga derechos a Adobe para incrustar el reproductor Flash] por ejemplo, tarda a veces en cargar, o directamente no carga el vídeo.

Sigo en otro momento… y no penséis que no tengo tabaco… acabo de abrir una cajetilla… 😀

Update 19 febrero 2017

(Actualización relámpago…).

No tengo tiempo porque estoy con ello, es uno de los “have-to(es)” que no tendría que estar haciendo, así que solamente voy a subir un recorte de pantalla de una herramienta de un programa que se llama VirtualDub, y que en una pestaña tiene el HexEditor, que permite ver el contenido de archivos muy grandes, de Gigas de tamaño, en hexadecimal, da a la izquierda la dirección (el desplazamiento), y a la derecha los valores de 16 en 16 bits (16 bits por fila), y su representación si es que tienen un valor representable en pantalla a la derecha.

Así encuentras por ejemplo que H.263 ,o H.264 , estándares de video  streaming, en  telefonía en la “nube”), si se “entienden” mal pueden dar (pasando de decimal a hexadecimal, cogiendo valores en BigEndian, que es por defecto el que usa Apple, resultados curiosos [y más si la “palabra en lugar de ser de 16 bits, es de DOCE, u OCHO, y las resoluciones son 4:3, por ejemplo]).

(Así que habría que hacer ‘strcmp’ (en C, C++, SQL…) carácter a carácter, cogidos de uno en uno, de dos en dos, de tres en tres, de cuatro en cuatro… de izquierda a derecha, y de derecha a izquierda y meter la salida (con un ‘|’)  como input.(avi u otra extensión), e ir probando).

[En ffmpeg hay un filtro -f segments que permite partir archivos de gran tamaño de forma que sean reproducibles, porque inserta cabeceras, parecido a “split” en linux, pero los ves todos si suministras los parámetros adecuados].

( Por eso no tengo tiempo, porque tengo que pensarlo, escribirlo, ejecutarlo e ir viendo qué sale).

Subo el recorte de pantalla y ya comentaré en otro momento.

(Si sale en  pequeño tamaño al abrir en otra pestaña, quitar esto en la barra de dirección del navegador, Chrome, Internet Explorer, Safari, Opera…) :

?w=640&h=361

[Enter]  🙂

Los índices se dan a veces en función de la fecha ICRT, las fechas se pueden sobreescribir y si el programa busca por fecha no encuentra el archivo.

-ts

(timestamp)

VirtualDub

Herramienta editor hexadecimal de VirtualDub

Acerca de María Cristina Alonso Cuervo

I am a teacher of English who started to write this blog in May 2014. In the column on the right I included some useful links and widgets Italian is another section of my blog which I called 'Cornice Italiana'. There are various tags and categories you can pick from. I also paint, compose, and play music, I always liked science, nature, arts, language... and other subjects which you can come across while reading my posts. Best regards.
Esta entrada fue publicada en Computer Science, English, Español, Hilarious, Language, Music, pulpito, Songs, Uncategorized, Video y etiquetada , , , . Guarda el enlace permanente.