HLS and HDS are both HTTP based streaming protocols, and sound very similar, but are

fundamentally very different. HLS stands for HTTP Live Streaming and is Apple's

proprietary streaming format based on MPEG2-TS. ... HDS stands for HTTP Dynamic
Streaming and is Adobe's format to deliver fragmented mp4 files (fMP4).

El Protocolo simple de administración de red o SNMP (del inglés Simple Network

Management Protocol) es un protocolo de la capa de aplicación que facilita el intercambio
de información de administración entre dispositivos de red.
SNMP se puede implementar usando comunicaciones UDP o TCP, pero por norma
general, se suelen usar comunicaciones UDP en la mayoría de los casos. Con UDP, el
protocolo SNMP se implementa utilizando los puertos 161 y 162. puerto 162
se utiliza para los mensajes de tipo “trap” o interrupción.

FileCatalyst se ha posicionado como la mayor solución de referencia para la transferencia

de archivos pesados, los cuales se pueden acelerar y aumentar.

Nimbra tiene opción de emplear RITS, un protocolo de transmisión de vídeo sobre líneas no
gestionadas, en cuyo fórum participa AWS Elementals.

He recibido consultas referente al tema de Zixi, y voy a intentar intentar explicar un poco su
funcionamiento.Quiero dejar claro que no soy ningún experto en Zixi, por tanto, que este
articulo sirva simplemente de orientación y si despierta vuestro interés, lo mejor es
contactar con Zixi donde os informaran con detalle www.zixi.com
Zixi es un protocolo*, para streaming o como queráis llamarlo , este protocolo es de pago y
se ha de pagar una licencia bien por uso de datos "Broadcaster"o bien una licencia por
equipo "Zixi Zystem".

*Lo defino como protocolo porque por mis limitaciones técnicas  no se  definirlo de otra forma,
seguro que más de uno dirá ,  esto no  es un protocolo por esto o otro......vale, vale seguro que sabe
más que yo, pero creo  llamándolo  protocolo todos me entienden, y si no, vuestros comentarios
siempre serán bien recibidos y así aprendemos todos.

Zixi aunque incrementa un poco la latencia, (retardo al recibir la señal) puede compensar

perdidas de datos de hasta un 30%. 
Esto puede ser interpretado de dos formas, la primera interpretación y para mi errónea, es
que se puede disminuir el ancho de banda en un 30% arriesgando mucho al trabajar al
limite, la segunda visión, que para mi es la más acertada, es la de que si tengo un bajada
puntual en el ancho de banda o un exceso de interferencias en el canal dispongo de un
30% de margen de seguridad.

La misma imagen con Zixi izquierda y Sin Zizi derecha

Con Zixi podemos trabajar de varias formas, una es con el que Zixi denomina
como Broadcaster. Broadcaster es el receptor-servidor de la señal, este se encuentra por
lo general en la nube y es donde dirigimos la señal de origen codificada con
protocolo* Zixi" desde "Zixi Freeder" y que luego el Broadcaster reenvía de nuevo a
los Zixi Receiver que entregarán el vídeo IP al decodificador (que no se muestra en el
dibujo) para obtener el Vídeo HD final.Las direcciones de envió y recepción se suministran
al adquirir la licencia "Broadcast".

En configuración parecida podríamos hacerlo con cámaras JVC, eliminando en este caso

"el encoder o codificador" y el "Zixi Feeder" puesto que todo esto ya esta incorporado
en las cámaras JVC. Usando este mismo flujo podríamos también sustituir los Zixi
receiver  y usar como variante Ordenadores con software VLC y plug-in Zixi.
Si quieres más información sobre el uso de VLC y Zixi encontraras más información al
final de este documento.
En cualquiera de los casos anteriores tendrás que pedir o comprar una licencia de
"Broadcaster". Mas información en http://www.tmediat.es/p-zixi.html o en www.zixi.com.

Luego esta el sistema P2P, punto a punto o como lo denomina Zixi, Zixi-link este sistema

lo podéis ver en la siguiente imagen, que al igual que en el primer ejemplo
trabaja decodificadores externos para generar el vídeo IP necesario para atacar al "Zixi
Feeder " luego se envía la señal IP de forma directa a través de la red o satélite
a "Zixi receiver" extrayendo la señal IP sin Zixi hacia el decodificador para obtener el
vídeo final. 

Utilizando cámaras JVC con USB HOST y el decodificador ProHd BR-DE800 el sistema

se simplifica enormemente. En este caso la licencia se compra para el uso con el
decodificador en concreto, por tanto quedan ligadas de por vida la licencia y el
decodificador, siendo en este caso la licencia de un pago único. Evidentemente
podremos atacar al mismo decodificador con diferentes cámaras siempre que la
transmisión no se haga de forma simultanea , es decir al decodificador BR-DE800 le debe
llegar una única señal en cada momento. 

Si utilizamos cámaras JVC , como ya he comentado estas ya llevan integrado el

codificador y el Zixi Feeder . En el siguiente diagrama podéis ver básicamente en bloques
el funcionamiento interno de la cámara JVC. Lo primero que hace la cámara  es un análisis
de la red o canal de transmisión para de forma dinámica dentro de unos margenes
coherentes codificar en función de la misma, (con más ancho de banda se comprime
menos y más calidad, si el ancho de banda es limitado se aumentara la compresión), de
esta forma ya inicialmente se eliminan errores. Por otro lado en el caso de que el ancho de
banda baje o fluctué se producen errores en la transmisión y podemos perder paquetes de
datos o estos llegar incompletos, en ese caso, es el receptor "Zixi receiver" o
decodificador "ProHd (BR-DE800)" con Zixi quien solicita a la cámara que envíe de nuevo
el paquete de datos perdido o dañado.

Para decodificar Zixi podemos hacerlo con un Zixi receiver + un decodificador o bien
simplemente con un BR-DE800 con licencia Zixi "licencia de pago único "Zixi -Link".

Aquí podéis ver resumidas las diferencias entre Zixi Broadcaster y Zixi Link, siendo el
Link a mi entender un perfecto aliado al uso en canales de noticias y deportes, ya que
pueden usar un gran parque de cámaras (una a la vez), y recibir así señal en directo desde
prácticamente cualquier punto. Esta señal procedente de cualquier cámara JVC (Host) u
otras con codificadores IP-Zixi externos pueden entrar en producción como una fuente más
de vídeo con garantías de estabilidad para directo. Esto permite a cualquier TV disponer de
multitud de unidades móviles (tantas como cámaras) y eliminar los enormes costes de
desplazamiento de una unidad móvil para cubrir directos en lugares donde con una sola
cámara o simplemente con algunos planos queda cubierto el evento.
Zixi Link y Zixi Eco Zystem son básicamente iguales en funcionamiento, en lo que
difieren básicamente es que Zixi Link utiliza equipos de Zixi (Zixi Feeder/Receiver)
mientras que Zixi-Zystem es aquel que usa la misma tecnología, pero esta, está integrada
en equipos de fabricantes asociados como es JVC, ViTEC,NewteK ,Teradek y otros.

Recordar que: JVC codifica internamente, por tanto la señal se extrae directamente del
procesador de imagen y se eliminan multitud de pasos previos a la codificación, esto da
como resultado una señal muy limpia y sin errores de manipulación , conversión o sub-
muestreo , esto queda claramente reflejado en la calidad de la codificación con imágenes
limpias, muy definidas y con un retardo o latencia inferior a si utilizamos decodificadores
externos.

BR-DE800.
En caso de que dispongamos de un decodificador BR-DE800 deberemos suministrar al
pedir la licencia el ID de nuestro decodificador.
 VLC con Plug-in Zixi, Guía de instalación rápida de
Windows
Traducción de documento original Zixi, descargar original aquí 

VLC es un reproductor multimedia libre que permite reproducir corrientes Zixi utilizando un
plug-in específico Zixi.
VLC con el plugin Zixi proporciona la posibilidad de ver en la calidad original y controlar
fácilmente los flujos procedentes de un Transmisor Zixi desde cualquier parte del mundo,
siempre y cuando exista suficiente ancho de banda y disponga de la licencia Transmisor.
Como usar Zixi con VLC
Procedimiento:
1. Verifique que VLC está instalado en su PC con Windows. Si no tiene instalado VLC
descárguelo de la página oficial http://www.videolan.org/vlc/ e instálelo siguiendo las
instrucciones, una vez instalado reinicie su PC.
2. Descargue e instale el plug-in Zixi de VLC
en: http://downloads.zixi.com/free/zixi_vlc_plugin-win32-1.9-latest.zip
3. Inicie la aplicación VLC y pulse Ctrl + N para abrir la sección "Open Media / Red".
Escriba la dirección URL del canal: Zixi: // /
Nota - Si tiene acceso a la interfaz de usuario del Broadcaster Zixi que está transmitiendo,
puede instalar el plug-in VLC y al elegir el flujo de entrada puede en luego en "Opciones"
-> "Reproducir con VLC '.
Latencia y FEC ajustes:
Latencia predeterminada es 6000ms. En caso se requiera disminuir o seleccionar otra
latencia, siga los pasos descritos a continuación para configurar un valor diferente:
1. Abra VLC
2. Presione CTRL + P (Herramientas-> Preferencias)

3. Seleccione "Todos" en la sección "Mostrar ajustes" (esquina inferior izquierda).

4. Expandir “Entrada / Codecs”, luego expandir “módulos de acceso ", Seleccione

“ Zixi”' 
5. Si lo desea cambie el “Max latency”
6. Haga clic en "Guardar"
7. Conéctese a su Stream
8. Verifique que el valor de latencia en la interfaz de usuario Transmisor “Broadcaster UI
(User Interface)”
9. Supervisar las estadísticas y afinar a la latencia adecuada para que no exista perdida en
la transmisión.

(Recomendación – Una alta latencia proporcionará una mejor robustez; permitir más de 4
segundos y hasta el máximo que sea posible. La regla de oro es permitir al menos [3x
(RTT + jitter) ms]. Para latencia por debajo de 1.500 ms, comprobar las estadísticas de
transmisión de streaming y añadir FEC (si es necesario).

En el caso de aplicaciones de baja latencia, podría ser necesario añadir FEC para mejorar
la recuperación de paquetes perdidos. Utilice los siguientes pasos para habilitar FEC en
VLC:
Siga los pasos descritos anteriormente..
1. Abra VLC
2. Presione CTRL + P (Herramientas-> Preferencias)
3. Seleccione "Todos" en la sección "Mostrar ajustes" (esquina inferior izquierda)
4. Expandir “Entrada / Codecs”, luego expandir “módulos de acceso ", Seleccione “ Zixi”'
5. Introduzca el porcentaje y tamaño de FEC. (Forward Error Corrección)

6. Haga clic en "Aceptar"

7. Conéctese a su Streaming.
8. Supervisar las estadísticas y ajustar la configuración de la FEC para que no exista
perdida en la transmisión.

Cómo comprobar si el Plug-in Zixi ya está instalado? :

1. Abra VLC
2. Presione CTRL + P (Herramientas-> Preferencias)
3. Seleccione "Todos" en la sección "Mostrar ajustes" (esquina inferior izquierda)
4. Expandir 'Entrada / Codecs', Expand "módulos de acceso",
5. Compruebe si 'Zixi' aparece en la lista de módulos

HOW RIST AND SRT WILL CHANGE

THE FACE OF BROADCAST
New Internet protocols allow not only safe distribution of mezzanine or
DTH live television channels, but also remote processing of video content
in public or private clouds.

The broadcast industry has witnessed in the past quarters a rapid

adoption of two new technologies, both in the realm of point-to-point
distribution of video over the public Internet. NAB 2019 was a good
illustration, with lots of stands in the South Upper hall adopting the “SRT
alliance” badge. SRT was initially developed by Haivision and is now
open-sourced. RIST is a newer standard but is supported by major
industry players such as Zixi, VideoFlow and Haivision.
Transmitting video streams over the Internet is not a new idea. In the
late 2000s I happened to be the main author of the “multicat” open-
source project, better known as the VideoLAN project. This project
features a couple of programs (aggregartp and reordertp) allowing
point-to-point delivery of an RTP stream with packet retransmission and
link aggregation. At the same time several protocols based on TCP
coexisted to distribute content to the end user: HTTP progressive
download or RTMP. TCP looks like an obvious choice to ensure the
reliability of the transmission, as it features built-in packet reordering
and packet retransmission.

However the downside is that the application doesn’t have any control
on the protocol itself, its timeouts, its windows of retransmission, etc.
Under bad network conditions, a typical TCP connection can freeze for
a minute before returning an error.
This is not acceptable in a professional environment, where fast
recovery is a must. UDP allows for a better control of the algorithm,
which improves the predictability of its behaviour. That is why I chose
UDP/RTP for multicat ten years ago, as well as other subsequent
proprietary or open implementations.
In the 2010s, two companies developed proprietary solutions for point-
to-point delivery over the Internet : VideoFlow and Zixi. They modelled
their price list over the prices for satellite contribution: per transferred
MB. As a result, you pay for your own bandwidth. The comparison with
satellite costs is however very favorable, and they were very successful.

Additionally, Zixi released its software in the form of an application,

installable on Windows and Linux operating systems, making it very
easy for both customers and manufacturers to integrate it. The
incredible success of these solutions awakened other players such as
Haivision, who began work on its SRT solution. As it arrived late in a
market already saturated by Zixi and VideoFlow, Haivision decided to
open source its solution. But with at least three solutions in the market
(smaller companies have also developed their own solutions: our
company OpenHeadend has been selling its transmit function based on
multicat for years), interoperability quickly became a concern. That is
why all these companies created the RIST forum and developed this
new protocol.
It is hard to say which of SRT and RIST will prevail. Both protocols are
similar: They are based on UDP, and use receiver feedback to
retransmit lost packets. But they also have their advantages and
drawbacks, summed up in the following table:
SRT supports encryption and multiple connection modes for the
receiver: “caller” (where the receiver calls the sender), “listener” (where
the receiver waits for incoming packets from the sender) and
“rendezvous” (both parties try to contact the other). This implies that
SRT only requires a public IP address (or a port forwarding) on one
end. RIST on the contrary requires a public IP address on both sides
and doesn’t support encryption, consequently RIST will probably be
most useful in combination with a VPN software such as “tinc”.
SRT has an additional feature, multiplexing, which allows for several
SRT connections on the same UDP port. Bonding is only supported in
RIST, with two possible modes: split (each route carries different
packets) or duplicate (redundant transmission).
But the most sensible difference is that SRT is what we call an “adhoc”
standard. It is not backed by a collegial, independently tested and
implemented specification, contrary to RIST, which is based on years of
developments at the IETF.
I personally know lots of broadcasters who are looking into SRT or
RIST as a cost-effective way to deliver their mezzanine streams to
remote network operators or service providers, in spite of expensive
private fibre optics or satellite links. But this is only the beginning:
Winter is coming.
Cloud platforms provide easy and affordable computing capabilities,
which are now widely used in many industries, including the web. But it
is still relatively marginal in the broadcast industry, with a scope
restricted to non-video related tasks (cloud-based traffic systems for
instance) or Internet distribution (AWS Elemental MediaLive and
MediaPackage being prime examples). But the advent of reliable
transport protocol will allow to move traditional broadcast streams to the
cloud for processing, and get them back for traditional distribution.
Most cloud software provider will support either SRT or RIST or both, so
that broadcasters only need to invest in “gateways”, moving data to or
from cloud servers, with their own SRT or RIST implementation. SRT
and RIST may also be used to transfer data between cloud servers, as
multicast is not common in these environments, and cloud providers
won’t warranty 100% reliability with regards to packet losses and
reordering.
Want more information? SRT source code can be downloaded
from GitHub. For RIST you can use VLC, gstreamer or Upipe.
Want a product? OpenHeadend supports both SRT and RIST since
version 10.1, and can act as a gateway between them.

By far the most visited video of 2019 was the Merrick Ackermans’ review of RIST first
release. RIST, the Reliable Internet Stream Transport protocol, aims to be an interoperable
protocol allowing even lossy networks to be used for mission-critical broadcast contribution.
Using RIST can change a bade internet link into a reliable circuit for live programme
material, so it’s quite a game changer in terms of cost for links.
An increasing amount of broadcast video is travelling over the public internet which is
currently enabled by SRT, Zixi and other protocols. Here, Merrick Ackermans explains the
new RIST specification which aims to allow interoperable internet-based video contribution.
RIST, which stands for Reliable Internet Stream Transport, ensures reliable transmission of
video and other data over lossy networks. This enables broadcast-grade contribution at a
much lower cost as well as a number of other benefits.
Many of the protocols which do similar are based on ARQ (Automatic Repeat-reQuest)
which, as you can read on wikipedia, allows for recovery of lost data. This is the core
functionality needed to bring unreliable or lossy connections into the realm of usable for
broadcast contribution. Indeed, RIST is an interesting merging of technologies from around
the industry. Many people use Zixi, SRT, and VideoFlow all of which can allow safe
contribution of media. Safe meaning it gets to the other end intact and un-corrupted.
However, if your encoder only supports Zixi and you use it to deliver to a decoder which
only supports SRT, it’s not going to work out. The industry as accepted that these formats
should be reconciled into a shared standard. This is RIST.
File-based workflows are mainly based on TCP (Transmission Control Protocol) although,
notably, some file transfer service just as Aspera are based on UDP where packet recovery,
not unlike RIST, is managed as part of the the protocol. This is unlike web sites where all
data is transferred using TCP which sends an acknowledgement for each packet which
arrives. Whilst this is great for ensuring files are uncorrupted, it can impact arrival times
which can lead to live media being corrupted.
RIST is being created by the VSF – the Video Standards Forum – who were key in
introducing VS-03 and VS-04 into the AIMS group on which SMPTE ST 2022-6 was then
based. So their move now into a specification for reliable transmission of media over the
internet has many anticipating great things. At the point that this talk was given the simple
profile has been formed. Whist Merrick gives the details, it’s worth pointing out that this
doesn’t include intrinsic encryption. It can, of course, be delivered over a separately
encrypted tunnel, but an intrinsic part of SRT is the security that is provided from within the
protocol.
Despite Zixi, a proprietary solution, and Haivision’s open source SRT being in competition,
they are both part of the VSF working group creating RIST along with VideoFlow. This is
because they see the benefit of having a widely accepted, interoperable method of
exchanging media data. This can’t be achieved by any single company alone but can benefit
all players in the market.
This talk remains true for the simple profile which just aims to recover packets. The main
protocol, as opposed to ‘simple’, has since been released and you can hear about it in a
separate video here. This protocol adds FEC, encryption and other aspects. Those who are
familiar with the basics may whoosh to start there.

Open GL

Progressive segmented Frame (PsF, sF, SF) is a scheme designed to acquire, store, modify,
and distribute progressive scan video using interlaced equipment.
With PsF, a progressive frame is divided into two segments, with the odd lines in one segment
and the even lines in the other segment. Technically, the segments are equivalent to
interlaced fields, but unlike native interlaced video, there is no motion between the two fields
that make up the video frame: both fields represent the same instant in time. This technique
allows for a progressive picture to be processed through the same electronic circuitry that is
used to store, process and route interlaced video.
The term progressive segmented frame is used predominantly in relation to high
definition video. In the world of standard definition video, which traditionally has been using
interlaced scanning, it is also known as quasi-interlace,[1] progressive recording[2] or movie mode.
[3]
 Other names for PsF used by electronic equipment manufacturers include progressive
recording (Sony), progressive scan mode (Sony), progressive shutter mode (Sony), frame
shutter mode (Sony), frame mode (Panasonic and Canon), Digital Cinema (Panasonic), Pro-
Cinema (Panasonic) and Cinema mode (Canon).

Contents
 1History
 2Usage
 3Similar technologies
o 3.12:2 pulldown (TV broadcast)
o 3.2PALplus film mode (TV broadcast)
o 3.3Video recorders
 4Variants
 5References

History[edit]
PsF was designed to simplify the conversion of cinematic content to different video standards,
and as a means of video exchange between networks and broadcasters worldwide.[4] Brought to
life by the movie industry in the end of the 1990s, the original PsF specification was focused on
24 frame/s content, resulting in existing interlaced equipment having to be modified for 48 Hz
scanning rate in order to work properly with 24 frame/s content.
Not everyone welcomed the PsF standard, however. Some industry observers maintained that
native 24p processing would have been a better and cleaner choice. Charles Poynton, an
authority in digital television, made the following remark in his book: "Proponents of [PsF]
scheme claim compatibility with interlaced processing and recording equipment, a dubious
objective in my view."[1] William F. Schreiber, former Director of the Advanced Television
Research Program at MIT, suspected that the continued advocacy of interlaced equipment
originated from consumer electronics companies that were trying to get back the substantial
investments they had made in obsolete technology.[5]

Usage[edit]
Despite the criticism, PsF quickly became a de facto standard for high quality film-to-video
transfer. One of the documented examples of PsF usage is the 2003 transfer of the film
"Terminator 2: Judgment Day" to DVD, performed by Artisan Entertainment and THX. The
original 24 frame/s movie was converted to PsF format and recorded to HD-D5 videotapes. This
allowed for the creation of a digital master that was nearly identical to the original film, and
made it possible to edit digitally at the native frame rate.[6] The same digital master appears to
be used for the 2006 Blu-ray Disc transfer of the movie.[7]
PsF has been recognized by Recommendation ITU-R BT.709 as a legitimate way to transport
progressive frames within an interlaced system. 25PsF and 30PsF rates have been added to
the specification in addition to the more established 24PsF. "Fractional" frame rates, having the
above values divided by 1.001, are also permitted; the resulting 23.976PsF and 29.97PsF rates
are used in 59.94 Hz systems. No change from 59.94 Hz systems to 60 Hz (although provided
for and anticipated) has occurred allowing display on analog NTSC color televisions and
monitors after down-conversion and encoding.
PsF became a means of initial image acquisition in professional Sony video cameras. It is
employed in HDCAM and XDCAM video cameras, including the HDW-F900 CineAlta camera
which was used by George Lucas for creating Star Wars, Episode 2, and by Alexander
Sokurov for creating Russian Ark fully in the digital domain.

Similar technologies[edit]
2:2 pulldown (TV broadcast)[edit]
2:2 pulldown is widely used in 50 Hz interlaced television systems to broadcast progressive
material recorded at 25 frame/s, but is rarely used in 60 Hz systems. The 2:2 pulldown scheme
had originally been designed for interlaced displays, so fine vertical details are usually filtered
out to minimize interline twitter. PsF has been designed for transporting progressive content and
therefore does not employ such filtering.
PALplus film mode (TV broadcast)[edit]
PALplus utilizes a digital stream embedded in the interlaced analog TV signal called widescreen
signaling, which, among other data, describes whether the signal should be treated as
interlaced ("camera mode") or progressive("film mode).[3]
Video recorders[edit]
PsF is utilized in some DV, HDV and AVCHD camcorders for 25-frame/s and 30-frame/s
progressive-scan recording. To achieve this, the camera acquires 30 (NTSC) or 25 (PAL)
independent images per second. These images are output as 60 (NTSC) or 50 (PAL) interlaced
fields. The result is a progressive-scan content, which is compatible with traditional interlaced
scanning systems.
This is how Sony described the progressive recording mode in the operating guide for a 60 Hz
("NTSC") Sony DCR-HC96 camcorder:
Note on the progressive recording mode
In a normal TV broadcast, the screen is divided into 2 finer fields and these are displayed in
turn, every 1/60 of a second. Thus, the actual picture displayed in an instant covers only half of
the apparent picture area. In progressive recording, the picture is fully displayed with all the
pixels.[2]
The booklet for the 50 Hz ("PAL") Sony DSR-PD175P camcorder describes its progressive
recording mode as follows:
Progressive Scan Mode
The 25p image captured by the sensor system is recorded as an interlaced signal by dividing
each frame into two fields. This enables compatibility with current editing and monitoring
equipment that only accept interlaced signals, while maintaining the quality of the 25p image.[8]
The operating instructions for the 60 Hz ("NTSC") Panasonic PV-GS500 camcorder describe its
progressive recording mode as follows:
Pro-Cinema function
In addition to the effects when the Wide function is used, images can also be recorded at a rate
of 30 frames a second with a strobe-like effect.[9]
The HDV Progressive Primer whitepaper mentions Progressive Segmented Frame mode:
Progressive Scan Mode
In this mode, the captured image is divided into two halves, then recorded or output as interlace
signal. The halves are called segments, not fields, because there is no temporal difference
between them. This method is also called as PsF (Progressive segmented Frame) recording.
The Progressive Scan mode is suitable for the feature films, documentaries, music videos which
have to be recorded as interlaced video for viewing on interlaced monitors, but want to offer
“progressive-look” to their motion. Besides, the video taken in the Progressive Scan mode can
be edited and output as true progressive video if needed.[10]
Consumer camcorders as well as most professional camcorders do not use PsF to record 24-
frame/s video; instead they either record it natively in progressive form or apply 2:3 pulldown.
Most video formats including professional ones utilize chroma subsampling to reduce amount
of chroma information in a video, taking advantage of the human visual system's lower acuity for
color differences than for luminance.[11] Such a reduction improves compression of the video
signal, which is always desirable because of storage and transmission limitations. To ensure
compatibility with interlaced-based systems, chroma information in PsF video is sometimes
recorded in interlaced format, despite that the content is progressive. This may result in
interlaced artifacts being noticeable on colored objects.[12]

Variants[edit]
  24PsF (48sF, 1080sf24, 1920×1080/24/1:1SF) is the original PsF format, which is used
in professional equipment for film-to-video transfer, for high definition mastering and for
video exchange between networks. This may be the first universal video standard which
transcends continental boundaries, an area previously reserved for film.[13]
 25PsF (1080sf25, 1920×1080/25/1:1SF) is used in 50 Hz systems for production that
originates on video and is targeted for television distribution.
 29.97PsF (1080sf29, 1920×1080/29.97/1:1SF) formats are sometimes used in 60 Hz
systems for sitcoms and music shows.[14][15] 29.97PsF as well as 30PsF (30p, 1080sf30,
1920×1080/30/1:1SF) formats are gaining popularity as an acquisition format for Web video
delivery, because most video hosting web sites cannot stream video with rates higher than
30 frame/s.

References[edit]
1. ^ Jump up to:a b Charles Poynton, Digital Video and HDTV: Algorithms and Interfaces.
2. ^ Jump up to:a b "DCR-HC36/HC46/HC96 Operating Guide"  (PDF). Sony Corporation. 2006.
Retrieved  2010-08-11.
3. ^ Jump up to:a b "All You Ever Wanted to Know About PALplus but were Afraid to Ask".
4. ^ "Jim Mendrala, A discussion of 24p frame and the new 48sF frame format".
5. ^ "The history and politics of DTV"  (PDF).
6. ^ "Terminator 2: Extreme Edition". Archived from  the original on 2008-05-31.
7. ^ "Terminator 2: Judgment Day (Blu-ray)".
8. ^ "DSR-PD175P: 1/3-inch 3 Exmor CMOS professional DVCAM camcorder".
9. ^ "Panasonic PV-GS500: operating instructions"  (PDF).
10. ^ HDV Progressive Primer  (PDF). Sony. p.  11.
11. ^ S. Winkler, C. J. van den Branden Lambrecht, and M. Kunt (2001). "Vision and Video:
Models and Applications". In Christian J. van den Branden Lambrecht (ed.). Vision models and
applications to image and video processing. Springer. p. 209.  ISBN  978-0-7923-7422-0.
12. ^ Adam Wilt (2009-01-12). "Review: Canon Vixia HF11 AVCHD camcorder". ProVideo
Coalition.
13. ^ "Steve Wiedemann, 24/P HDTV: The Fall of Film Production".
14. ^ "'Beside You in Time' by Nine Inch Nails was encoded as interlaced" .
15. ^ "Sony BDP-S350 Blu-ray Player review".
Categories: 
 Film and video technology

En el pasado post analizamos el protocolo NTP para sincronización de tiempo. Hoy

revisaremos el protocolo PTP (Precisión Time Protocol) está recogido en la norma
IEEE 1588v2 y surgió como necesidad para aquellas aplicaciones que necesitan
una precisión superior a la que nos permite el protocolo NTP. En PTP pasamos a
precisiones por debajo de los microsegundos mientras en NTP podemos tener
precisiones del rango de milisegundos.

El protocolo PTP se basa en una arquitectura maestro/esclavo donde ambos nodos

intercambian paquetes específicos para sincronizarse entre ellos. A través de estos
paquetes el sincronismo se distribuye a través de todos los nodos de la red.
BMC (Best Master Clock)
En PTP definimos dominios. Un dominio es un grupo de nodos que se sincronizan
a partir de la mejor fuente de reloj disponible. El algoritmo que permite determinar
cuál es esta mejor fuente de reloj se denomima BMCA (Best Master Clock
Algorithm). Todos los relojes del dominio intercambian paquetes Announce entre
ellos y a través de la información intercambiada deciden cuál es el mejor reloj
(GMC o Grand Master Clock). La elección del GMC se basa en múltiples aspectos
tales como la fuente interna de reloj, la precisión del propio nodo o la variabilidad
con el tiempo de dicha referencia. Normalmente el GMC suele ser un nodo que
extrae la referencia de tiempo de una señal GPS o un oscilador de gran precisión
(OCXO o incluso Rubidio). En un dominio sólo puede haber un único GMC. En
caso de caída o pérdida de sincronismo de este nodo, otro nodo asumirá el papel
de nuevo GMC.

Tipos de relojes
En función de cómo se distribuye el reloj por los diferentes nodos de la red, éstos
nodos pueden asumir los siguientes roles:

 Ordinary clock (OC): es un nodo con un único puerto PTP que funciona en modo
slave. Es un nodo terminal de red que recibe la sincronización a través de este puerto
slave.
 Boundary clock (BC): es uno nodo que tiene múltiples puertos PTP. A través del
protocolo BMC (Best Master Clock) cada puerto identifica su mejor reloj. Si el mejor
reloj es un nodo externo, dicho puerto se configurará como slave sincronizándose a
partir del puerto master del nodo externo conectado. Si por el contrario el propio puerto
es el mejor reloj, éste se configurará como master permitiendo la sincronización de los
slaves conectados a dicho puerto. Los boundary clock actúan como elementos
intermedios en la red y permiten la interconexión y sincronismo entre diferentes
dominios PTP.
 Transparent clock (TC): estos nodos no participan del mecanismo BMC y por
tanto no actúan propiamente como master o slave. Simplemente intentan dejar pasar
los paquetes PTP de la forma más transparente posible. Hay dos tipos:
 End-to-End transparent clock (E2E): cuando un paquete PTP traspasa el
nodo, se le añade a la salida el tiempo de tránsito del paquete dentro del nodo
 Peer-to-Peer transparent clock (P2P): en este caso, además del tiempo de
tránsito le añadimos también el retardo del nodo anterior. De esta forma tenemos
realmente el offset total de tiempo del paquete PTP desde el anterior nodo a la
salida del P2P.

En la siguiente figura vemos de forma gráfico una red PTP con los diferentes tipos
de relojes.
Protocolo NTP – Los Miércoles de Tecnología
POSTED ON POSTED ON18/04/2018BYJOSÉ RAMÓN SALVADOR

El protocolo NTP (Network Time Protocol) permite la sincronización horaria de

cualquier equipo o dispositivo conectado a una red de comunicaciones.

Se trata de un protocolo cliente/servidor donde los equipos que deben

sincronizarse actúan como clientes lanzando peticiones de sincronismo (NTP
request) a otro u otros dispositivos que actúan como servidor y que entregan la
fecha y hora exacta (NTP reply). El intercambio de mensajes así como un resumen
del cálculo del offset o retardo entre envío de petición y recepción de respuesta
puede verse en la siguiente figura.

Fuente: ADVA y
Osciloquartz
El protocolo NTP se estructura de una forma jerárquica donde un mismo equipo o
nodo de la red puede actuar como cliente y servidor al mismo tiempo. Como
servidor atiende las peticiones NTP de los equipos inferiores y como cliente solicita
el tiempo con mayor precisión a los equipos superiores tal y como se muestra en la
siguiente figura. También algunos equipos pueden funcionar en modo ‘peer’
obteniendo el reloj de otro servidor pero pudiendo, a su vez, entregar el reloj a
dicho servidor si así éste lo solicita.

Tal y
como se muestra en la figura, el reloj o sincronismo se va degradando a medida
que bajamos de nivel ya que cada transacción cliente/servidor implica una pérdida
de precisión derivada de los retardos variables de transmisión y de proceso de los
paquetes NTP en cada uno de los nodos intermedios. A mayor número Stratum,
menor precisión del reloj.

GPO
Directiva de Grupo es una característica de Windows NT, familia de Sistemas Operativos.
Directiva de grupo es un conjunto de reglas que controlan el entorno de trabajo de cuentas de
usuario y cuentas de equipo. Directiva de grupo proporciona la gestión centralizada y
configuración de sistemas operativos, aplicaciones y configuración de los usuarios en un
entorno de Active Directory. En otras palabras, la Directiva de Grupo, en parte, controla lo que
los usuarios pueden y no pueden hacer en un sistema informático. Aunque la Directiva de
Grupo es más frecuente en el uso de entornos empresariales, es también común en las
escuelas, las pequeñas empresas y otros tipos de organizaciones más pequeñas. Directiva de
grupo a menudo se utiliza para restringir ciertas acciones que pueden presentar riesgos de
seguridad potenciales, por ejemplo: Bloquear el acceso al Administrador de tareas, restringir el
acceso a determinadas carpetas, deshabilitar la descarga de archivos ejecutables, etc.
¿Qué es un CDN?
Una CDN (Red de Distribución de Contenido o Content Delivery Network, por sus
siglas en inglés) es un conjunto de servidores ubicados en diferentes zonas
geográficas que contienen copias locales de los contenidos de los clientes.

Una CDN (Content Delivery Network o Red de Distribución de

Contenido en español) es básicamente un conjunto de
servidores ubicados en diferentes puntos de una red
que contienen copias locales de ciertos
contenidos (vídeos, imágenes, música, documentos, webs,
etc.) que están almacenados en otros servidores generalmente
alejados geográficamente, de forma que sea posible servir
dichos contenidos de manera más eficiente.
Esta mejora en la eficiencia se logra con un mejor balanceo
de la carga a la que están sometidos tanto los servidores que
alojan los contenidos como los enlaces que interconectan las
distintas secciones de la red, eliminando posibles cuellos de
botella y sirviendo los datos en función de la cercanía
geográfica del usuario final.
DSCP no es más que un código con el que se marcan los paquetes ToS  (type of service)
de la cabecera IP y que es utilizado por una técnica llamada Difserv (Servicios
difereciciados) para implementar QoS en redes IP

Básicamente Diffserv de basa en marcar paquetes IP mediante un código llamado DSCP

utilizando el campo ToS de la cabecera IP. Los router y switches de la red pueden leer el
campo DSCP y priorizan el tráfico indicado mediante técnicas de encolado del tráfico.

Calidad de Servicio QoS (Quality of Service)

por Javier Rejón | 11 marzo, 2016

0 comentarios

Para entender bien qué es Qos, qué implicaciones tiene y cómo opera en la red, hay que ir por 
partes. El concepto de QoS implica una serie de técnicas y protocolos destinados a mantener
unos requerimientos en diversos aspectos de una conexión. Estos requerimientos son las
calidades del servicio que se pretende salvaguardar. El concepto de calidad del servicio es
tremendamente amplio y pueden referirse a temas como el tiempo de respuesta, pérdidas de
información, capacidad de reconexión, etc. Calidad del servicio es también proveer prioridades
a aplicaciones, flujos de datos y usuarios.

En términos de transmisión de datos normalmente se refiere a mecanismos de control para la

reserva de recursos asociados a dichas calidades. Con ello se pretende eliminar o minimizar el
impacto de problemas como el bajo rendimiento, retardos, latencia, jitter, desorden en los
paquetes de información y errores.

Para poder llevar a cabo el QoS en redes de datos, existen diversos mecanismos o estrategias
que se sirven de protocolos o reglas específicas. Estos mecanismos de QoS pueden ser
independientes del medio de transmisión o capa dos (por ejemplo Diffsev que opera a nivel
IP) , o estar implementados en estrecha relación con el medio de transmisión como por ejemplo
ATM.

Estrategias y mecanismos de implementación de QoS

En redes de comunicaciones existen dos mundos bien distintos: conmutación de paquetes y

conmutación de circuitos. En general los protocolos de conmutación de circuitos como ATM,
Frame-Realy o GSM ya incorporan calidad del servicio en su propia definición del protocolo y
no necesitan de procedimientos adicionales para implementarla.

En redes de conmutación de paquetes, como Ethernet e IP, se necesitan mecanismos

adicionales. Estos mecanismos se pueden diferenciar en dos categorías:

  Modelo priorizado de servicios diferenciados.

Denominado Diffserv se trata de marcar paquetes según un tipo de servicio deseado. Los
routers y switches de la red usan por lo general estrategias de encolado del tráfico para
priorizar el tráfico atendiendo a dicha marca en el paquete.

 Modelo parametrizado de servicios integrados.

En este modelo son las aplicaciones las que reservan un recurso a lo largo de la red mediante
un protocolo de reservación de recurso. Actualmente está en desuso en redes grandes debido
a sus problemas de escalabilidad. Su principal exponente fue el protocolo RSVP.
Por otra parte en cuanto a la capa dos,  también es posible marcar paquetes para un
tratamiento especial en la red. En el caso de redes Ethernet el estándar 802.1p utiliza una
cabecera 802.1Q (VLAN) para implementar un nivel de ocho prioridades o calidades de servicio
usando el campo user_priority de tres bits de la cabecera 802.1Q añadida a la trama.

Otra técnica de capa dos es MPLS, la cual añade etiquetas en dicho nivel, asignando distintos
niveles de QoS. MPLS realiza la conmutación de paquetes en función de dichas etiquetas
independientemente de la tecnología de transporte. Por ello MPLS permite servicios
multiprotocolo y es portable sobre distintas tecnologías de enlace como Ethernet, ATM, Frame-
Relay, etc.

Una vez encuadrado QoS en las redes de datos, vamos a entrar en un poco más de detalle en
algunos aspectos.

El campo type of service (ToS) de la cabecera IP

Cuando se creó IP, se incluyó en su cabecera un campo de 8 bits llamado ToS (type of service)
o tipo de servicio. Este campo ha tenido varios usos a lo largo del tiempo y ha sido redefinido
en varias RFCs.

Inicialmente se dividía en dos subcampos: Precedencia y Tipo de Servicio. En concreto el

campo Precedencia era de tres bits y asociaba al paquete un rango de prioridad de 0 a 7.

0 1 2 3 4 5 6 7

Precedence Type of Service

IP PRECEDENCE (BITS 1,2 Y 3) SIGNIFICADO

0 (000)  Best Effort Valor por defecto, tráfico rutinario

1 (001) Priority Prioritario

2 (010) Immediate Inmediato

3 (011) Flash Flash, usado en señalización de voz principalmente

4 (100) Flash Override Anulación de Flash

5 (101) Critical Crítico, VozIP, etc.

 6 (110) Internetwork Control Control de interred

7 (111) Network Control  Reservado para protocolos de control de red

En cuanto al subcampo Type of Service, cada bit tenía un significado específico según esté a 0
o a 1:

Bit 3: Retardo (0=retardo normal 1=bajo retardo)

Bit 4: Rendimiento (0=rendimiento normal, 1=alto rendimiento)
Bit 5: Fiabilidad (0=fiabilidad normal, 1=alta fiabilidad)
Bit 6: Coste (0=coste normal, 1=bajo coste)
Bit 7: Reservado (siempre a cero)

Esto actualmente ya no se utiliza. En la actualidad el campo ToS de la cabecera IP se utiliza

para albergar dos tipos de subcampos, uno llamado DSCP (Differentiated Services Code Point)
utilizando los primeros 6 bits y otro llamado ECN (Explicit Congestion Notification) utilizando los
dos bits restantes, según RFCs 3260 y 3168.

Campo DSCP (6 bits) Campo ECN (2 bits)

DSCP no es más que un código con el que se marcan los paquetes ToS de la cabecera IP y
que es utilizado por una técnica llamada Difserv para implementar QoS en redes IP.

ECN es un mecanismo de notificación de estados de congestión entre extremos el cual permite

evitar el descarte de paquetes IP entre dos elementos con ECN habilitado cuando la red
subyacente también la soporta. No lo tratamos aquí.

Diffserv (Servicios difereciciados) y DSCP

Básicamente Diffserv de basa en marcar paquetes IP mediante un código llamado DSCP

utilizando el campo ToS de la cabecera IP. Los router y switches de la red pueden leer el
campo DSCP y priorizan el tráfico indicado mediante técnicas de encolado del tráfico.

DSCP se transporta en los seis primeros bits del campo ToS, es decir, permite 64 valores
diferentes. Pero para mantener cierta compatibilidad con los tres bits de Precedencia, el campo
de  seis bits del DCSP se dividió en dos grupos. Los tres primeros bits tienen el mismo
significado que el IP Precedence y marcan una prioridad en el paquete. Los tres últimos bits
significan Drop Preference y también marcan un segundo nivel de órden en el posible
descartado de paquetes. El valor que tiene más peso es el de Precedence. Si dos paquetes
tienen el mismo Precedence, cuanto más pequeño sea del Drop Preference menos
probabilidad de ser descartado.

El código DSCP puede ser introducido en la cabecera IP por el propio host, para marcar el
switch qué tráfico es más prioritario. Por supuesto los switches y routes pueden introducir el
código DSCP a determinado tipo de tráfico que se considere prioritario en la red. Además los
switches y routres pueden también cambiar el código DSCP entrante por otro distinto, alterando
el tratamiento de un determinado tipo de tráfico en la red.
En DSCP el concepto IP Precedence se llama Class Selector. Lógicamente hay ocho Class
Selectors: CS0-CS7, y para cada CS podría haber hasta otros ocho posibles Drop Preference
aunque no se utilizan todos ya que sólo se usan dos bits del subcampo. El binomio CS-Drop
Preference ha derivado en lo que se conoce como PHB (Per Host Behavior). Algunos CS
tienen nombres especiales, como se verá en las siguientes tablas. Por último algunos CS se
denominan también Assured Forwarding (AF) y van seguidos de dos números según el valor
del Drop Preference.

DSCP BINARY DECIMAL BEHAVIOR EQUIVALENT IP PRECEDENCE VALUE

CS0 (Default) 000 000 0  Best effort  Best effort

CS1 001 000 8 AF1  Priority

CS2 010 000 16 AF2  Immediate

CS3 011 000 24 AF3  Flash

CS4 100 000 32 AF4  Flash override

CS5 101 000 40 EF (Expedited Forwarding)  Critical

CS6 110 000 48 Internetwork control  Internetwork control

CS7 111 000 56  Network control  Network control

Para cada AF de han definido tres prioridades de descartes y nombrados como AFxy,
donde x es el AF correspondiente y la y asigna una probabilidad de descarte. Así tenemos de
AF11 al AF13, AF21 al AF23 y así hasta el AF43.
DSCP DECIMAL DROP EQUIVALENT IP PRECEDENCE

VALUE VALUE MEANING PROBABILITY VALUE

000 000 0 Best effort N/A 000 – Routine

001 010 10 AF11 Low 001 – Priority

001 100 12 AF12 Medium 001 – Priority

001 110 14 AF13 High 001 – Priority

 010 010 18 AF21 Low 010 – Immediate

010 100 20 AF22 Medium 010 – Immediate

010 110 22 AF23 High 010 – Immediate

011 010 26 AF31 Low 011 – Flash

011 100 28 AF32 Medium 011 – Flash

011 110 30 AF33 High 011 – Flash

100 010 34 AF41 Low 100 – Flash override

100 100 36 AF42 Medium 100 – Flash override

100 110 38 AF43 High 100 – Flash override

Expedited forwarding
101 110 46 (EF) N/A 101 – Critical

110 000 48 Internetwork control N/A 110 – Internetwork control

111 000 56 Network control N/A 111 –  Network control

Así por ejemplo, en una red mixta datos-VoPI marcaríamos los paquetes de voz con DSCP 46
en los hosts de origen o en los switches de acceso y haríamos que los routers y switches de
transporte priorizaran ese tráfico.