Technology

Todo lo que siempre has querido saber sobre la norma SCTE-35

La norma SCTE-35 es una de las más importantes en el ámbito de la radiodifusión y el streaming, y una de las menos comprendidas fuera de los equipos de ingeniería que trabajan con ella a diario. Si alguna vez te has preguntado por qué se ha emitido una pausa publicitaria en el momento equivocado, por qué tu plataforma SSAI no ha detectado un punto de empalme, o qué significan realmente todos esos valores hexadecimales en un mensaje de señalización, esta guía es para ti.

Abordaremos todos los aspectos: la historia, la estructura binaria, todos los tipos de comandos de empalme, la tabla completa de identificadores de tipo de segmentación (Segmentation Type ID), los formatos UPID y cómo los sistemas reales —desde la radiodifusión ATSC hasta el streaming HLS— implementan el SCTE-35 en la práctica.

1. ¿Qué es SCTE-35?

SCTE-35 es una norma publicada por la Sociedad de Ingenieros de Telecomunicaciones por Cable (SCTE), cuyo título oficial es Mensaje de señalización de inserción de programas digitales para cable. Define un formato de mensaje binario para la señalización de eventos —principalmente oportunidades publicitarias— dentro de un flujo de vídeo digital.

El estándar se publicó por primera vez en 1999 y se ha revisado en múltiples ocasiones, siendo las versiones más extendidas la SCTE-35 2019 y la SCTE-35 2022. A pesar de que su nombre hace referencia al cable, la SCTE-35 es ahora el estándar universal de señalización publicitaria para los flujos de trabajo de cable, satélite, IPTV, OTT y streaming.

En esencia, el SCTE-35 responde a una pregunta sencilla: «En este preciso momento de la transmisión, está a punto de ocurrir algo importante: ¿qué es, y ¿qué deben hacer al respecto los sistemas posteriores?» Ese «algo» suele ser una pausa publicitaria, pero también puede ser el límite de un programa, un marcador de capítulo, un evento de interrupción de la señal o un identificador de contenido personalizado.

2. Dónde se ubica el SCTE-35 en la pila

Los mensajes SCTE-35 se transmiten como una sección privada dentro de un flujo de transporte MPEG-2 (MPEG-2 TS). Ocupan su propio PID (identificador de paquete), que se declara en la PMT (tabla de mapa de programas) del programa al que se refieren. La entrada de la PMT para el PID de SCTE-35 utiliza el tipo de flujo 0x86.

En la transmisión HLS y DASH, los mensajes de señalización SCTE-35 se transmiten de forma diferente:

  • HLS: Los datos SCTE-35 se codifican en base64 y se insertan como #EXT-X-CUE-OUT, #EXT-X-DATERANGE o #EXT-X-SCTE35 en el manifiesto. El binario sin procesar también se incrusta en los segmentos de la secuencia de transporte para los sistemas que analizan a nivel de TS.
  • DASH: Los eventos SCTE-35 se transmiten como elementos EventStream dentro del MPD, o como cuadros emsg (cajas de mensajes de evento, definidas en ISO BMFF) dentro de los segmentos multimedia.

El recorrido de un mensaje SCTE-35 a través de una cadena de emisión típica implica tres capas distintas, cada una con una función claramente definida. Un error común es pensar que el sistema de tráfico se comunica directamente con el codificador; no es así. La cadena correcta es:

  1. Tráfico y programación (intención): El sistema de tráfico o programación define qué debe suceder y cuándo —por ejemplo, una pausa publicitaria de 2 minutos que comienza a las 20:12:30. Esto se modela como un evento secundario (una disponibilidad, un marcador de pausa o una oportunidad de inserción) vinculado a la programación principal. El sistema de tráfico expresa la intención; no se comunica directamente con los codificadores ni con el hardware de emisión.
  2. Automatización y emisión (ejecución): El sistema de automatización de emisión lee la programación y, en el momento adecuado, ejecuta el evento secundario. Es el sistema de automatización —no el de tráfico— el que envía un mensaje SCTE-104 a través de IP al codificador o al multiplexor, normalmente entre 4 y 10 segundos antes del punto de empalme. El sistema de automatización puede activar simultáneamente servidores de emisión, sistemas gráficos, salidas GPI y otros componentes posteriores.
  3. Codificador / Multiplexor (generación de SCTE-35): Al recibir la instrucción SCTE-104, el codificador o multiplexor la convierte en un mensaje de señal binaria SCTE-35 y la incrusta en el flujo de transporte MPEG-2 en el PTS (marcador de tiempo de presentación) correcto. Este es el punto en el que la señal entra en el dominio de distribución comprimida.
  4. Distribución: El flujo de transporte (TS) recorre la cadena de distribución (enlace ascendente por satélite, ingesta en la CDN, empaquetador). Cada sistema puede recodificar o dejar pasar los datos SCTE-35.
  5. Empaquetado: El empaquetador (por ejemplo, Elemental MediaPackage, Unified Origin, Evrideo) lee la señal SCTE-35 y escribe las etiquetas de manifiesto adecuadas para la distribución HLS/DASH.
  6. Inserción de anuncios: El sistema SSAI lee las etiquetas del manifiesto, envía una solicitud de decisión publicitaria e inserta el creativo publicitario devuelto en la transmisión en el punto de empalme.

Un modelo mental útil: El departamento de tráfico programa la intención. La automatización ejecuta el desencadenante. El codificador emite el SCTE-35.

3. La estructura binaria del SCTE-35

Un mensaje SCTE-35 es una estructura de datos binaria. Comprender su estructura es esencial para la depuración, la creación de analizadores sintácticos y la verificación de que su codificador o empaquetador esté generando mensajes correctos.

La estructura de nivel superior es la splice_info_section:

splice_info_section() {
  table_id 8 bits   // Siempre 0xFC
  section_syntax_indicator 1 bit    // Siempre 0
  private_indicator 1 bit    // Siempre 0
  reserved 2 bits
  section_length 12 bits   // Bytes que siguen a este campo
  protocol_version 8 bits   // Siempre 0x00
  paquete_cifrado 1 bit    // 1 si la carga útil está cifrada
  algoritmo_de_cifrado 6 bits   // 0x00 = sin cifrado
  ajuste_pts 33 bits   // Se suma a todos los valores PTS del mensaje
  cw_index 8 bits   // Índice de la clave de cifrado
  tier 12 bits   // Nivel de direccionabilidad
  splice_command_length 12 bits   // Longitud del comando de empalme
  splice_command_type 8 bits   // Identifica el comando (véase más abajo)
  [splice_command()] // Carga útil del comando de longitud variable
  descriptor_loop_length 16 bits   // Longitud total de todos los descriptores
  [splice_descriptor()]* // Cero o más descriptores
  [alignment_stuffing]* // Relleno para alinear con el límite de byte
  [E_CRC_32] 32 bits   // CRC de la parte cifrada (si está cifrada)
  CRC_32 32 bits   // CRC-32 de toda la sección
}

Explicación de los campos clave

table_id (0xFC): Siempre es 0xFC (252 en decimal). Es el identificador de la tabla de secciones privadas MPEG-2 para SCTE-35. Cualquier analizador sintáctico puede identificar una sección SCTE-35 mediante este byte.

pts_adjustment: Un valor de 33 bits que se añade a cada marca de tiempo PTS dentro del mensaje. Se utiliza cuando el flujo ha sufrido un «enrollamiento» de PTS o discontinuidades. En la mayoría de los flujos normales es cero, pero debe tenerse en cuenta en cualquier analizador que cumpla con el estándar.

tier: Un campo de direccionabilidad de 12 bits. El valor 0xFFF significa que el mensaje se aplica a todos los niveles (el valor por defecto para la mayoría de las implementaciones). Los niveles no predeterminados se utilizan en entornos de cabecera de cable, donde diferentes grupos de abonados reciben contenido publicitario distinto.

splice_command_type: El byte más importante del mensaje. Indica al sistema receptor de qué tipo de evento se trata. Consulte la sección 4 para ver la tabla completa de tipos de comando.

4. Tipos de comando de empalme

El campo splice_command_type identifica qué estructura de comando le sigue. El estándar SCTE-35 define seis tipos de comando:

HexadecimalDecimalNombre del comandoDescripción
0x000splice_null()Un mensaje de latido o de mantenimiento de conexión. No contiene datos de temporización ni de eventos. Se utiliza para mantener la presencia del PID SCTE-35 en el flujo.
0x044splice_schedule()Programa uno o más eventos de empalme futuros utilizando la hora real UTC (UTC_splice_time). Rara vez se utiliza en implementaciones modernas; ha sido sustituido por splice_insert y time_signal.
0x055splice_insert()El comando original de inserción de publicidad. Señala un único evento de inserción o salida con una sincronización basada en PTS. Ampliamente utilizado en la radiodifusión por cable y satélite.
0x066time_signal()Un mensaje de sincronización genérico que, por sí solo, no tiene ningún significado implícito. Su significado viene definido íntegramente por los descriptores de segmentación (segmentation_descriptor) que se le adjuntan. Es el tipo de comando preferido para flujos de trabajo de OTT y streaming.
0x077bandwidth_reservation()Reserva ancho de banda en el PID SCTE-35 para futuros mensajes. Rara vez se utiliza en la práctica.
0xFF255private_command()Un comando específico del proveedor identificado mediante un identificador de 32 bits. No es interoperable sin un acuerdo previo entre el remitente y el destinatario.

splice_insert() en detalle

splice_insert() es el comando original de SCTE-35 y sigue utilizándose ampliamente en entornos de cable y satélite. Su estructura es:

splice_insert() {
  splice_event_id 32 bits   // Identificador único del evento
  splice_event_cancel_indicator    1 bit    // 1 = cancelar un evento enviado previamente
  reservado 7 bits
  if (splice_event_cancel_indicator == 0) {
    out_of_network_indicator 1 bit    // 1 = empalme OUT (a publicidad), 0 = empalme IN (de vuelta al contenido)
    program_splice_flag 1 bit    // 1 = se aplica a todos los componentes
    duration_flag 1 bit    // 1 = sigue break_duration()
    splice_immediate_flag 1 bit    // 1 = empalme en la próxima oportunidad
    reservado 4 bits
    if (program_splice_flag == 1 && splice_immediate_flag == 0) {
 splice_time() // PTS del punto de inserción
    }
    if (duration_flag == 1) {
 break_duration() // Duración prevista de la pausa
    }
    unique_program_id 16 bits   // Identificador del programa
    avail_num 8 bits   // Número de espacios publicitarios dentro de la pausa
    avails_expected 8 bits   // Total de espacios publicitarios en esta pausa
  }
}

El out_of_network_indicator es el campo clave: 1 significa «salir del contenido de la cadena y pasar a un anuncio» (empalme OUT), mientras que 0 significa «volver al contenido de la cadena» (splice IN). Una pausa publicitaria completa requiere tanto un mensaje splice OUT como un mensaje splice IN.

time_signal() en detalle

time_signal() es más sencilla: solo transporta una marca de tiempo PTS:

time_signal() {
  splice_time()   // PTS del evento
}

splice_time() {
  time_specified_flag 1 bit    // 1 = sigue el PTS
  if (time_specified_flag == 1) {
    6 bits reservados
    pts_time 33 bits   // reloj PTS a 90 kHz
  } else {
    7 bits reservados
  }
}

Por sí sola, una time_signal() no hace nada. Su significado proviene íntegramente del segmentation_descriptor() adjunto en el bucle del descriptor. Por eso time_signal() + segmentation_descriptor() se ha convertido en el patrón estándar para las implementaciones modernas de OTT y streaming: es mucho más expresivo que splice_insert().

5. Descriptores de empalme

Los descriptores son extensiones opcionales adjuntas a cualquier comando splice. Contienen metadatos adicionales más allá de los que proporciona el propio comando. El campo descriptor_loop_length de la sección splice_info_section indica la longitud total en bytes de todos los descriptores que le siguen.

Cada descriptor comienza con una cabecera común:

splice_descriptor() {
  splice_descriptor_tag 8 bits   // Identifica el tipo de descriptor
  descriptor_length 8 bits   // Longitud de los datos del descriptor
  identificador 32 bits   // Siempre 0x43554549 («CUEI» en ASCII)
  [datos específicos del descriptor]
}

El campo identificador 0x43554549 es la codificación ASCII de «CUEI» — el identificador de registro SCTE. Cualquier descriptor con un identificador diferente es una extensión privada o de proveedor.

La norma SCTE-35 define cuatro tipos de descriptores:

EtiquetaNombreFinalidad
0x00avail_descriptor()Proporciona información adicional sobre disponibilidad (espacios publicitarios), incluido un identificador de disponibilidad del proveedor.
0x01DTMF_descriptor()Transmite secuencias de tonos DTMF para sistemas de inserción analógicos heredados.
0x02segmentation_descriptor()El descriptor más importante. Define los límites del contenido, los tipos de segmentos y los identificadores de contenido. Véase la sección 6.
0x03time_descriptor()Proporciona el TAI (Tiempo Atómico Internacional) y el desfase respecto al UTC para una sincronización precisa del reloj de pared.

6. El segmentation_descriptor() — El corazón del SCTE-35 moderno

El segmentation_descriptor() (etiqueta 0x02) es, con diferencia, la parte más importante y compleja del estándar SCTE-35. Es lo que transforma una señal de sincronización genérica en un evento de contenido significativo. Comprenderlo en su totalidad es esencial para cualquiera que desarrolle o depure sistemas SSAI, de empaquetado o de marcado de contenido.

Estructura de segmentation_descriptor()

segmentation_descriptor() {
  splice_descriptor_tag 8 bits   // 0x02
  longitud_del_descriptor 8 bits
  identificador 32 bits   // 0x43554549 («CUEI»)
  id_del_evento_de_segmentación 32 bits   // Identificador único del evento
  indicador_de_cancelación_del_evento_de_segmentación  1 bit
  reservado 7 bits
  si (indicador_de_cancelación_del_evento_de_segmentación == 0) {
    indicador_de_segmentación_del_programa 1 bit
    indicador_de_duración_de_la_segmentación     1 bit    // 1 = sigue el campo de duración
    indicador_de_entrega_sin_restricciones   1 bit    // 1 = sin restricciones de entrega
    si (indicador_de_entrega_sin_restricciones == 0) {
 indicador de entrega web permitida    1 bit
 indicador de ausencia de bloqueo regional    1 bit
 indicador de archivo permitido 1 bit
 restricciones de dispositivo 2 bits   // 0x3 = ninguna
    } else {
 reservados 5 bits
    }
    if (program_segmentation_flag == 0) {
 component_count 8 bits
      for (i = 0; i < número_de_componentes; i++) {
 etiqueta_del_componente 8 bits
 reservados 7 bits
 desplazamiento_pts 33 bits
 }
    }
    if (bandera_de_duración_de_segmentación == 1) {
 duración_de_segmentación 40 bits   // Duración en ticks de 90 kHz
    }
    tipo_de_UPID_de_segmentación 8 bits   // Tipo de UPID (véase la sección 7)
    longitud_upid_segmentación 8 bits   // Longitud del UPID en bytes
    upid_segmentación() // Los datos del UPID
    id_tipo_segmentación 8 bits   // De qué tipo de segmento se trata (véase la sección 8)
    segment_num 8 bits   // Número de segmento dentro de un grupo
    segments_expected 8 bits   // Total de segmentos esperados
    if (segmentation_type_id == 0x34 || segmentation_type_id == 0x36 ||
        segmentation_type_id == 0x38 || segmentation_type_id == 0x3A) {
 sub_segment_num 8 bits
 sub_segments_expected 8 bits
    }
  }
}

Indicadores de restricción de entrega

Cuando delivery_not_restricted_flag es 0, el descriptor contiene cuatro indicadores de restricción de entrega que los sistemas posteriores deben respetar:

  • web_delivery_allowed_flag: 0 = no distribuir este segmento a través de la web (Internet). Se utiliza para contenidos con restricciones de derechos en Internet.
  • no_regional_blackout_flag: 0 = aplicar las normas de bloqueo regional. Se utiliza para derechos deportivos en los que se debe bloquear la transmisión a los espectadores fuera del mercado.
  • archive_allowed_flag: 0 = no archivar este segmento. Se utiliza para derechos de contenido exclusivamente en directo.
  • device_restrictions: Un campo de 2 bits que restringe la distribución a clases específicas de dispositivos (0x0 = solo dispositivos restringidos, 0x3 = sin restricciones).

segmentation_duration

Cuando se establece segmentation_duration_flag, el campo de 40 bits segmentation_duration contiene la duración prevista del segmento en ticks de reloj de 90 kHz. Para convertirlo a segundos, hay que dividirlo por 90 000. Por ejemplo, una pausa publicitaria de 30 segundos se señalaría como 2 700 000 ticks (0x0029ACA0).

Este campo es orientativo: indica a los sistemas posteriores cuánto tiempo se espera que dure la pausa, pero el final real se señala mediante el mensaje «End» con el tipo_id correspondiente. Los sistemas SSAI utilizan este valor para precargar el material publicitario con la duración correcta.

7. segmentation_upid_type — La tabla completa

El UPID (identificador único de programa) es un identificador de contenido incluido en el segmentation_descriptor. El campo segmentation_upid_type define el formato del identificador. Se trata de uno de los campos más importantes para la identificación de contenidos, la gestión de derechos y la publicidad dirigida.

HexDecNombreFormato y Descripción
0x000No se utilizaSin UPID. segmentation_upid_length deberá ser 0.
0x011Definido por el usuarioObsoleto. Formato definido por el operador. Sin garantía de interoperabilidad.
0x022ISCIIdentificador comercial estándar del sector. Código ASCII de 8 caracteres utilizado en la publicidad televisiva norteamericana. Obsoleto, sustituido por Ad-ID.
0x033Ad-IDIdentificación digital publicitaria. Identificador ASCII de 12 caracteres para creatividades publicitarias, gestionado por el registro Ad-ID. El identificador estándar para la publicidad televisiva y digital en Norteamérica.
0x044UMIDIdentificador único de material de la SMPTE (SMPTE 330M). Identificador binario de 32 bytes para material audiovisual, ampliamente utilizado en sistemas profesionales de gestión de activos de radiodifusión.
0x055ISANNúmero Internacional Normalizado Audiovisual (ISO 15706). En desuso en favor del V-ISAN (0x06). Identificador binario de 12 bytes para obras audiovisuales.
0x066V-ISANISAN con versión (ISO 15706-2). Identificador binario de 12 bytes que amplía el ISAN con un componente de versión, lo que permite identificar versiones específicas (p. ej., montaje del director, versión doblada) de una obra audiovisual.
0x077TIDIdentificador de programa de Tribune Media Systems. Identificador ASCII de 12 caracteres del servicio de datos de programación de Tribune (ahora Gracenote). Ampliamente utilizado en los sistemas norteamericanos de guía electrónica de programación (EPG) y de gestión de derechos.
0x088TIAiringID (anteriormente «Turner Identifier»). Cadena ASCII de longitud variable utilizada por Turner Broadcasting para identificar las emisiones de programas. Se utiliza junto con la infraestructura de toma de decisiones publicitarias de Turner.
0x099ADIIdentificador ADI (Asset Distribution Interface) de CableLabs. Cadena ASCII de longitud variable con el formato PAID:asset_id, utilizada en los flujos de trabajo de VOD por cable.
0x0A10EIDRRegistro de Identificadores de Entretenimiento (EIDR). Una representación binaria de 12 bytes de un DOI (Identificador de Objeto Digital) del EIDR. El EIDR es un registro global de contenidos utilizado para películas, series de televisión y episodios.
0x0B11Identificador de contenido ATSCIdentificador de contenido ATSC A/57B. Una estructura de longitud variable que contiene un TSID (identificador de flujo de transporte) y una cadena de identificación de contenido, utilizada en entornos de radiodifusión ATSC.
0x0C12MPU()UPID privado gestionado. Un formato estructurado que permite transportar identificadores privados o propietarios de forma estandarizada. Contiene un identificador de formato de 32 bits (registrado en SMPTE) seguido de datos privados.
0x0D13MID()Identificador múltiple. Una lista de UPID de diferentes tipos, que permite que un único evento de segmentación transporte varios identificadores simultáneamente (por ejemplo, tanto un Ad-ID como un EIDR para el mismo activo).
0x0E14Información ADSInformación publicitaria. Cadena ASCII de longitud variable que contiene metadatos de toma de decisiones publicitarias. El formato lo define el operador.
0x0F15URIIdentificador Uniforme de Recursos. Una cadena URI ASCII de longitud variable. El tipo de UPID más flexible y ampliamente utilizado en las implementaciones modernas de OTT y streaming. Puede contener cualquier esquema URI (urn:uuid:, http:, etc.).
0x1016UUIDIdentificador Único Universal (RFC 4122). Un UUID binario de 16 bytes. Introducido en SCTE-35 2020. Proporciona un identificador compacto y único a nivel mundial sin la sobrecarga de una cadena URI completa.
0x1117SCRRespuesta de consentimiento del suscriptor. Se utiliza en flujos de trabajo de publicidad direccionable para transmitir señales de consentimiento. Introducido en SCTE-35 2022.

El URI UPID en la práctica

El URI UPID (0x0F) es el tipo más utilizado en las implementaciones modernas de streaming. Su flexibilidad lo hace adecuado para una amplia gama de casos de uso:

  • Identificación de programas: urn:uuid:c7451a50-e053-4b2a-ca37-bae1df2cf1c8 — un URN basado en un UUID que identifica de forma única un programa o un episodio.
  • Toma de decisiones publicitarias: urn:adid:ABCD1234EFGH — un Ad-ID transmitido como un URN.
  • Marcado de contenido personalizado: Los operadores pueden definir sus propios esquemas URI para flujos de trabajo propios, tal y como se describe en la sección 9.

8. segmentation_type_id — La tabla completa

El segmentation_type_id es el campo que define qué tipo de límite de contenido representa este mensaje. Es el campo principal que utilizan los sistemas SSAI, los empaquetadores y reproductores utilizan para decidir qué acción llevar a cabo. La norma SCTE-35 define un conjunto exhaustivo de identificadores de tipo organizados en grupos lógicos.

HexadecimalDecimalMensaje de segmentaciónNotas
0x000No indicadoSin tipo de segmentación específico. Se utiliza cuando el tipo se transmite por otros medios.
0x011Identificación de contenidoTransporta un identificador de contenido (UPID) sin señalar un límite. Se utiliza para el marcado de contenido y la identificación de derechos. Se utiliza habitualmente con formatos UPID personalizados para flujos de trabajo de marcado de contenidos propietarios.
0x1016Inicio del programaMarca el inicio de un programa. Se combina con «Fin del programa» (0x11).
0x1117Fin del programaMarca el final de un programa.
0x1218Finalización anticipada del programaIndica que un programa finaliza antes de lo previsto. Se utiliza en eventos en directo (por ejemplo, un evento deportivo que termina antes de la hora prevista).
0x1319Interrupción del programaIndica una interrupción temporal de la programación prevista (p. ej., para un boletín de noticias de última hora).
0x1420Reanudación del programaIndica el regreso al programa previsto tras una interrupción.
0x1521Prolongación planificada del programaIndica que el programa actual durará más de lo previsto y que la prolongación se ha planificado con antelación.
0x1622Extracción no planificada del programaIndica una extensión no planificada del programa (por ejemplo, un evento en directo que se alarga).
0x1723Inicio de solapamiento de programasIndica el inicio de un programa que se solapa con el programa anterior.
0x1824Anulación de la restricción de emisiónAnula una restricción de emisión señalada previamente, permitiendo que la transmisión continúe.
0x1925Inicio del programa — En cursoIndica que un programa ya ha comenzado (se utiliza al incorporarse a una transmisión a mitad del programa, p. ej., tras un cambio de canal o al incorporarse a la transmisión).
0x2032Inicio de capítuloMarca el inicio de un capítulo dentro de un programa. Los capítulos son subdivisiones de un programa.
0x2133Fin de capítuloMarca el final de un capítulo.
0x2234Inicio de una pausaIndica el inicio de una pausa de contenido (no necesariamente una pausa publicitaria; podría ser una pausa de la emisora, una actualización de noticias, etc.).
0x2335Fin de la pausaIndica el final de una pausa de contenido.
0x2436Inicio de los créditos inicialesMarca el inicio de los créditos iniciales. Introducido en SCTE-35 2020.
0x2537Fin de los créditos inicialesMarca el final de los créditos iniciales.
0x2638Inicio de los créditos finalesMarca el inicio de los créditos finales.
0x2739Fin de los créditos de cierreMarca el final de los créditos de cierre.
0x3048Inicio de publicidad del proveedorMarca el inicio de un espacio publicitario controlado por el proveedor. El proveedor de contenidos (cadena) controla el inventario publicitario en este espacio.
0x3149Fin de la publicidad del proveedorMarca el final de un espacio publicitario controlado por el proveedor.
0x3250Inicio de la publicidad del distribuidorMarca el inicio de un espacio publicitario controlado por el distribuidor. El distribuidor (operador de cable, MVPD) controla el inventario.
0x3351Fin de la publicidad del distribuidorMarca el final de un espacio publicitario controlado por el distribuidor.
0x3452Inicio de la oportunidad de colocación del proveedorMarca el inicio de una oportunidad de colocación del proveedor (PO). Es más detallada que un espacio publicitario y se utiliza para la inserción dinámica de anuncios en streaming.
0x3553Fin de la oportunidad de colocación del proveedorMarca el final de una oportunidad de colocación del proveedor.
0x3654Inicio de la oportunidad de colocación del distribuidorMarca el inicio de una oportunidad de colocación del distribuidor.
0x3755Fin de la oportunidad de colocación del distribuidorIndica el final de una oportunidad de colocación del distribuidor.
0x3856Inicio de una oportunidad de colocación superpuesta de un proveedorIndica el inicio de una oportunidad publicitaria superpuesta de un proveedor (por ejemplo, un banner o una superposición de banda L).
0x3957Fin de la oportunidad de colocación de superposición del proveedorMarca el final de una oportunidad de superposición del proveedor.
0x3A58Inicio de la oportunidad de colocación de superposición del distribuidorMarca el inicio de una oportunidad de anuncio de superposición del distribuidor.
0x3B59Fin de la oportunidad de inserción de superposición del distribuidorMarca el final de una oportunidad de superposición del distribuidor.
0x3C60Inicio de la promoción del proveedorMarca el inicio de un. Introducido en SCTE-35 2022.
0x3D61Fin de la promoción del proveedorMarca el final de un segmento promocional del proveedor.
0x3E62Inicio de la promoción del distribuidorMarca el inicio de un segmento promocional del distribuidor.
0x3F63Fin de la promoción del distribuidorMarca el final de un segmento promocional del distribuidor.
0x4064Inicio de evento no programadoMarca el inicio de un evento en directo no programado (por ejemplo, noticias de última hora, emisión de emergencia).
0x4165Fin del evento no programadoMarca el final de un evento no programado.
0x4266Inicio de la oportunidad de contenido alternativoMarca el inicio de un intervalo en el que se puede sustituir el contenido por otro alternativo. Introducido en SCTE-35 2020.
0x4367Fin de la oportunidad de contenido alternativoMarca el final de una oportunidad de contenido alternativo.
0x4468Inicio del bloque publicitario del proveedorMarca el inicio de un bloque publicitario controlado por el proveedor. Introducido en SCTE-35 2022.
0x4569Fin del bloque publicitario del proveedorMarca el final de un bloque publicitario del proveedor.
0x4670Inicio del bloque publicitario del distribuidorMarca el inicio de un bloque publicitario controlado por el distribuidor.
0x4771Fin del bloque publicitario del distribuidorMarca el final de un bloque publicitario del distribuidor.
0x5080Inicio de redMarca el inicio de un segmento de red (el límite de mayor nivel en la jerarquía).
0x5181Fin de la redMarca el final de un segmento de red.

La distinción entre proveedor y distribuidor

Una de las distinciones conceptuales más importantes en la tabla type_id es la que existe entre los eventos de proveedor y distribuidor. Esto refleja la estructura comercial de dos niveles del mercado publicitario televisivo:

  • El proveedor (por ejemplo, una cadena de televisión como NBC, CNN o Sky) controla el inventario publicitario nacional o de la cadena. Los espacios publicitarios del proveedor son vendidos por la cadena y son uniformes en todas las plataformas de distribución.
  • El distribuidor (por ejemplo, un operador de cable, un MVPD o una plataforma OTT) controla el inventario publicitario local o regional. Los espacios publicitarios del distribuidor son vendidos por el propio distribuidor y pueden sustituirse por anuncios dirigidos a un público local.

Los sistemas SSAI utilizan esta distinción para determinar a qué sistema de toma de decisiones publicitarias deben recurrir y qué inventario deben cubrir. Una plataforma SSAI de un distribuidor normalmente solo actuará sobre los identificadores de tipo «Distribuidor», dejando los espacios publicitarios del proveedor para el propio sistema de inserción publicitaria de la cadena.

9. Formato UPID en la práctica: marcado de contenido personalizado

Más allá de los tipos de UPID estándar, muchos operadores implementan flujos de trabajo de marcado de contenido personalizado utilizando el UPID URI (0x0F) con segmentation_type_id = 0x01 (identificación de contenido). Este es el patrón descrito en el ejemplo que aparece al principio de este artículo.

El enfoque general consiste en codificar una carga útil estructurada como un URI o una cadena separada por comas dentro del campo UPID. Dado que el campo UPID está limitado a 255 bytes, el formato JSON suele resultar poco práctico, por lo que se prefieren los formatos separados por comas o delimitados por barras.

Ejemplo: Marcado personalizado de límites de contenido

Un patrón habitual utilizado por los proveedores de contenido para señalar los límites de contenido dentro de un marcador SCTE-35 utiliza un UPID separado por comas con tres componentes:

  1. Identificador de tipo de datos: Un número mágico fijo que identifica el formato (p. ej., 0x01010101), lo que permite a los receptores distinguir este formato personalizado de otros UPID de tipo URI.
  2. ID de evento principal: Un URN o UUID que identifica el programa o la producción (p. ej., urn:uuid:c7451a50-e053-4b2a-ca37-bae1df2cf1c8).
  3. Lista de etiquetas de límite: Una lista delimitada por barras de valores de etiquetas hexadecimales que identifican qué límites de contenido representa este marcador.

Un ejemplo completo:

0x01010101,urn:uuid:c7451a50-e053-4b2a-ca37-bae1df2cf1c8,10/31

Esto se lee así: «Para el programa c7451a50-e053-4b2a-ca37-bae1df2cf1c8, este marcador representa un inicio de bumper (0x10) y un final de patrocinio (0x31)».

Los valores de las etiquetas de límite los define el operador. Una tabla de etiquetas típica podría tener este aspecto:

Nombre de la etiquetaValor hexadecimalDecimal
Inicio de bumper0x1016
Fin de la cuña0x1117
Inicio de la promoción0x2032
Fin de la promoción0x2133
Inicio del patrocinio0x3048
Fin del patrocinio0x3149
Inicio del programa0x4064
Fin del programa0x4165
Inicio del capítulo0x5080
Fin del capítulo0x5181
Inicio de la pausa0x6096
Fin de pausa0x6197
Inicio de segmento0x70112
Fin de segmento0x71113

¿Por qué hay varias etiquetas en un mismo marcador?

Un único punto en la línea temporal del contenido puede representar varios límites simultáneos. Por ejemplo, el momento en que termina un bumper es también el momento en que termina un segmento de patrocinio; ambos eventos tienen lugar en el mismo fotograma. Codificar ambas etiquetas en un único mensaje SCTE-35 resulta más eficiente que enviar dos mensajes separados con el mismo PTS, y evita condiciones de carrera en los sistemas posteriores.

10. SCTE-35 en HLS: etiquetas de manifiesto

Cuando un empaquetador convierte un flujo TS a HLS, debe traducir los mensajes binarios SCTE-35 a etiquetas de manifiesto HLS. Existen tres enfoques principales, y las diferentes plataformas admiten unos u otros.

#EXT-X-CUE-OUT / #EXT-X-CUE-IN

El enfoque más sencillo y con mayor compatibilidad. El empaquetador escribe una etiqueta #EXT-X-CUE-OUT con la duración de la pausa antes del primer segmento de la pausa publicitaria, y una etiqueta #EXT-X-CUE-IN después del último segmento:

#EXT-X-CUE-OUT:DURATION=30.0
#EXTINF:6.006,
segment_0042.ts
#EXTINF:6.006,
segment_0043.ts
...
#EXT-X-CUE-IN

#EXT-X-DATERANGE

Los datos SCTE-35 se transmiten como un atributo codificado en base64 dentro de una etiqueta #EXT-X-DATERANGE, conservando la carga útil binaria completa para los analizadores posteriores:

#EXT-X-DATERANGE:ID="splice-6FFFFFF0",START-DATE="2026-05-21T14:00:00.000Z",
  PLANNED-DURATION=30.0,SCTE35-OUT=0xFC002F0000000000FF...

#EXT-X-SCTE35

Una extensión no estándar, pero muy utilizada, que transporta directamente el binario SCTE-35 codificado en base64 sin procesar:

#EXT-X-SCTE35:CUE="/DAlAAAAAAAAAAP/wFAVIAACPf+/wgAFQAABQAABQAAAAAAAA=="

11. SCTE-35 en DASH: EventStream y emsg

En DASH, los eventos SCTE-35 se transmiten en dos lugares:

  • EventStream del MPD: Los datos SCTE-35 están codificados en base64 y se colocan en un elemento <Event> dentro de un <EventStream> del MPD. El schemeIdUri es urn:scte:scte35:2014:xml+bin para los eventos codificados en binario.
  • cuadros emsg: Los eventos SCTE-35 se transmiten como cuadros de mensajes de evento ISO BMFF (emsg) dentro de los propios segmentos multimedia. El scheme_id_uri es urn:scte:scte35:2013:bin para el formato binario o urn:scte:scte35:2014:xml+bin para el formato más reciente.

12. SCTE-104: El protocolo de señalización ascendente

SCTE-35 define el formato de los mensajes en la secuencia de transporte comprimida. SCTE-104 define cómo se solicitan dichos mensajes en sentido ascendente —concretamente, la interfaz IP entre el sistema de automatización de emisión y el codificador o multiplexor que genera los mensajes SCTE-35.

Es importante comprender dónde se sitúa el SCTE-104 en la cadena. El sistema de tráfico/programación define eventos secundarios (franjas disponibles, marcadores de corte, oportunidades de inserción) como parte de la programación; se trata de expresiones de intención, no de órdenes de ejecución. El sistema de automatización/emisión lee esos eventos programados y, en el momento adecuado, envía un mensaje SCTE-104 al codificador, normalmente entre 4 y 10 segundos antes del punto de empalme. El sistema de tráfico nunca se comunica directamente con el codificador.

En entornos de emisión en la nube, la función del codificador de hardware tradicional suele ser sustituida por un multiplexor de software o un empaquetador de origen, pero la relación lógica sigue siendo la misma: la automatización activa el SCTE-104 (o un comando API equivalente) y el codificador/empaquetador emite el SCTE-35.

Se envía un mensaje SCTE-104 a través de UDP/IP desde el sistema de automatización al codificador. El codificador convierte la instrucción SCTE-104 en un mensaje binario SCTE-35 y lo inserta en la secuencia de transporte en el PTS correcto.

Los principales tipos de mensajes SCTE-104 son:

  • splice_request_data: Solicita un splice_insert() en un momento especificado.
  • segmentation_descriptor_request_data: Solicita un time_signal() + segmentation_descriptor() con los parámetros especificados.
  • insert_descriptor_request_data: Solicita la inserción de un descriptor específico.

13. Errores comunes de implementación

Tras años de trabajar con SCTE-35 en docenas de implementaciones de radiodifusión y streaming, estos son los errores más comunes con los que nos encontramos:

Olvidar el ajuste de PTS

El campo pts_adjustment debe añadirse a todos los valores de PTS del mensaje. Muchos analizadores ignoran este campo y utilizan los valores PTS sin procesar, lo que provoca errores de sincronización cuando la transmisión ha sido objeto de manipulación del PTS (por ejemplo, tras un remultiplexado de TS o tras una discontinuidad del PTS).

Coincidencia incorrecta de splice_event_id

El splice_event_id en un splice_insert() o el segmentation_event_id en un segmentation_descriptor() deben coincidir entre los mensajes «out» y «in» correspondientes al mismo evento. Las discrepancias hacen que los sistemas SSAI traten el mensaje «in» como un nuevo evento en lugar del cierre del «out», lo que da lugar a pausas publicitarias descontroladas.

Falta de segmentation_duration en los mensajes «Start»

Los sistemas SSAI utilizan el campo segmentation_duration para precargar el creativo publicitario. Si no aparece en un mensaje «Start» de oportunidad de colocación del proveedor o distribuidor, muchos sistemas de toma de decisiones publicitarias no enviarán una solicitud, lo que dará lugar a un espacio publicitario sin cubrir.

Envío exclusivo de «Out» sin «In»

Cada empalme OUT o inicio de segmento debe ir acompañado de un empalme IN o fin de segmento correspondiente. Los mensajes sin emparejar dejan a los sistemas posteriores en un estado indefinido. Algunas plataformas SSAI agotan el tiempo de espera tras la duración prevista, pero esto no está garantizado.

Tipo de UPID incorrecto para la carga útil

El envío de un UUID como URI UPID (0x0F) cuando debería ser un UUID UPID (0x10), o el envío de una cadena URN como UMID binario provoca errores de análisis en los sistemas posteriores que validan el tipo de UPID según el formato de la carga útil.

Errores de CRC debidos al remultiplexado

Cuando se remultiplexa una secuencia de transporte (por ejemplo, durante la transcodificación o el empaquetado), se debe volver a calcular el CRC de las secciones SCTE-35. Si se transmite el CRC original tras cualquier modificación de la sección, los receptores descartarán el mensaje por estar dañado.

14. Depuración de SCTE-35

Cuando los mensajes SCTE-35 no se comportan como se espera, estas son las principales herramientas y técnicas:

  • Analizadores sintácticos de SCTE-35: Herramientas como python-scte35, threefive y scte35-js pueden decodificar cargas útiles SCTE-35 en formato base64 o hexadecimal sin procesar, convirtiéndolas en estructuras legibles para el ser humano. Son esenciales para verificar la salida del codificador.
  • Inspección del manifiesto HLS: Utiliza curl o un analizador de manifiestos para inspeccionar el manifiesto HLS en directo y verificar que las etiquetas de señalización estén presentes, tengan el formato correcto y se encuentren en los límites adecuados de los segmentos.
  • Wireshark: Para la depuración de SCTE-104, captura el tráfico UDP entre el sistema de automatización y el codificador y decodifica los mensajes SCTE-104.
  • Modo de depuración de SSAI: La mayoría de las plataformas SSAI ofrecen un modo de depuración o de paso directo que registra cada solicitud y respuesta de decisión publicitaria, lo que permite rastrear exactamente qué evento SCTE-35 desencadenó cada solicitud publicitaria.
  • Análisis de la línea de tiempo PTS: Herramientas como tsduck y ffprobe pueden extraer los valores PTS de las secciones SCTE-35 de un archivo TS, lo que permite verificar que los mensajes llegan en el momento correcto en relación con los fotogramas de vídeo.

Conclusión

El SCTE-35 es un estándar aparentemente sencillo, pero en realidad es muy complejo. A simple vista, parece un mecanismo de señalización sencillo: un indicador en la transmisión que dice «aquí hay una pausa publicitaria». En la práctica, se trata de un sistema de metadatos de contenido rico y jerárquico que sustenta miles de millones de dólares en ingresos publicitarios cada año, tanto en la radiodifusión como en el streaming.

Comprender la estructura completa —desde el diseño binario de splice_info_section hasta los matices del formato UPID y la distinción entre el tipo de proveedor y eldistribuidor — es lo que diferencia a los equipos que monetizan de forma fiable sus contenidos de aquellos que pierden ingresos por oportunidades perdidas, eventos desajustados y pausas sin cubrir.

En Evrideo, la gestión del SCTE-35 está integrada en el núcleo de nuestra infraestructura de emisión, empaquetado y SSAI. Si te enfrentas a un reto de integración del SCTE-35 o quieres comprender cómo gestiona Evrideo la señalización publicitaria en tu flujo de trabajo específico, ponte en contacto con nuestro equipo.

Volver al blog