stringtranslate.com

Charla: estándares ATSC

¡Colores de imágenes/gráficos para una mejor usabilidad!

Utilice colores en los gráficos que sean fáciles de distinguir incluso con deficiencia de visión entre el rojo y el verde. También si otros colores pueden parecer más vistosos (como esos verdes y naranjas que están demasiado juntos, especialmente cuando el gráfico tiene un tamaño pequeño). Prefiera el contraste claro al estilo. Y usa amarillo también. Gracias, mejoraría mucho la usabilidad. - Comentario anterior sin firmar agregado por 87.179.148.231 (discusión) 05:18, 28 de noviembre de 2015 (UTC) [ respuesta ]

Submuestreo de croma

Este artículo no tiene ninguna información sobre el submuestreo de croma (4:2:0, 4:2:2?) utilizado en los distintos modos. Viento solar

Ubicación del artículo

¿Quién tuvo la tonta idea de trasladar el ATSC al Comité de Sistemas Avanzados de Televisión ? Nadie lo buscará ni lo vinculará bajo ese término y el acrónimo sigue siendo inequívoco. Lo único que hace son redireccionamientos innecesarios y enlaces engorrosos, donde una de las características clave de los wikis es la facilidad de vinculación. Christoph Päper 14:23, 12 de marzo de 2005 (UTC)


No estoy de acuerdo. Casi todas las abreviaturas tienen una página de desambiguación. Para mantener la coherencia, ATSC también debería conservar el nombre completo como clave. Por cierto, ¿es correcto este inglés? "Las emisoras que usan ATSC y deben retener una señal analógica tienen que transmitir en dos canales separados, ya que el sistema ATSC requiere el uso de un canal completo de seis megahercios". Usuario: Treeos 14:52, 30 Diciembre de 2005 (UTC)

1080p60?

¿Alguna novedad sobre el ATSC y el estándar 1080p60? Jack Zhang 01:32, 8 de abril de 2006 (UTC) [ respuesta ]

Ciertamente no he oído hablar de ningún plan al respecto, e imagino que funcionaría bastante mal dadas las limitaciones de ancho de banda y el hecho de que sólo se permite vídeo mpeg-2. Snacky 04:04, 14 de noviembre de 2006 (UTC) [ respuesta ]

¿Límite de seis canales?

¿Alguien puede proporcionar una cotización de algún estándar que limite el número de programas DTV por frecuencia a 6? Si bien no he buscado los estándares, creo que no existe tal limitación, y deduzco que esto fue escrito por la misma persona bien intencionada pero engañada que escribió la información errónea "1 programa por MHz". Snacky 06:20, 27 de mayo de 2006 (UTC) [ respuesta ]

Mi comprensión era un límite de cuatro o seis. Pero no tengo acceso, en este momento, a las publicaciones en las que leí esto, y fue en 1998. Presidente Lethe 15:12, 27 de mayo de 2006 (UTC) [ respuesta ]
Definitivamente no son cuatro. ¿Esta publicación era un estándar ATSC? Snacky 16:10, 27 de mayo de 2006 (UTC) [ respuesta ]

"Seis canales" es un límite pragmático basado en la calidad subjetiva resultante. ATSC no existe ninguna restricción más allá de la impuesta por ISO/IEC 13818-1 (Tabla 2-18), que utiliza un campo de 4 bits en stream_id para identificar el número de flujo de video. Por tanto, son posibles dieciséis canales. algocu 12:41, 20 de septiembre de 2006 (UTC)

Parece que tienes razón y gracias por responder. Además, ¡gracias por las recientes mejoras al artículo! Todo lo que tengo que añadir es que, para ser realmente pedante, el límite de 16 transmisiones de vídeo no te limita a sólo 16 canales virtuales. Puedes reutilizar las mismas transmisiones en canales virtuales como quieras. Esto es bastante inútil, pero lo he visto hecho con audio. Snacky 00:45, 21 de septiembre de 2006 (UTC) [ respuesta ]
stream_id especifica el tipo de codificación, es decir, MPEG-1 frente a MPEG-2. Efectivamente, no existe un límite absoluto en la cantidad de transmisiones en ATSC, tiene 1048575 canales VCT posibles. En MPEG, puede utilizar varias secciones PAT y PMT para lograr la cantidad de programas que desee. Entonces, el único límite absoluto son sus 8191 PID en un flujo de transporte MPEG. Si elimina los PID generales y asume una transmisión de audio por programa y con una transmisión de video de imagen estática compartida, aún puede incluir más de 8000 canales. Entonces, el límite real parecería ser la cantidad de transmisiones de audio con tasa de bits mínima que podría incluir en 6 Mhz con codificación QAM-256 u 8-VSB.
El número_canal_menor en el PSIP debe estar entre 1 y 99 para tipo_servicio ATSC_Televisión_Digital y para Audio_Only = un máximo de 99 multidifusiones de programas. Para datos de tipo de servicio, el número de canal menor debe estar entre 1 y 999 = un máximo de 999 multidifusiones de datos. -Dawn McGatney 69.139.231.9 (discusión) 09:51, 22 de abril de 2008 (UTC) [ respuesta ]

señal amigo

En el artículo no queda claro si un sintonizador ATSC puede mostrar una señal PAL. ¿Alguien que sepa esto puede actualizar el artículo con esta información? —El comentario anterior sin firmar fue agregado por Gaashish (discusión • contribuciones ).

¿Por qué lo haría? PAL es un estándar analógico. Snacky 04:06, 14 de noviembre de 2006 (UTC) [ respuesta ]

Lo siento, no todos somos expertos ;-) Ciertamente no soy un experto en esta área. Por lo tanto, aclare su respuesta: si compro un televisor LCD en los EE. UU., con sintonizador ATSC/NTSC, ¿puedo conectarlo al cable en los Países Bajos (PAL)? Perdón por mi ignorancia....

En teoría, un televisor ATSC puede mostrar cualquier vídeo compatible con PAL (576i), pero probablemente tendrás problemas con la recepción. La mitad analógica NTSC mostrará la imagen en blanco y negro, pero no en color. Y la mitad digital ATSC no es compatible con los estándares europeos de Televisión Digital. Así que realmente no tiene sentido intentarlo. - Theaveng 19:53, 26 de septiembre de 2007 (UTC) [ respuesta ]
Los televisores HDTV estadounidenses más nuevos tienen sintonizadores ATSC y NTSC; ninguno puede recibir transmisiones PAL. -Dawn McGatney 69.139.231.9 (discusión) 09:55, 22 de abril de 2008 (UTC) [ respuesta ]

ATSC versus digital terrestre

No veo por qué se compara ATSC con estándares digitales terrestres como DVB-T o ISDB-T en algunos puntos del artículo en lugar de comparar ATSC con los estándares más generales DVB e ISDB. -- Abdull 14:53, 14 de marzo de 2007 (UTC) [ respuesta ]

Porque ATSC es un estándar terrestre. - Theaveng 19:55, 26 de septiembre de 2007 (UTC) [ respuesta ]

¿Tierra-Luna-Tierra?

Parece una investigación original; Además, los sistemas prácticos de radioaficionados no pueden implementar esto y es probable que no lo hagan durante décadas. N8EVV también conocido como Marc W. Abel 04:49, 28 de junio de 2007 (UTC) [ respuesta ]

DT2

¿Un canal DT2 es parte de ATSC? Si es así, ¿hay algún artículo que diga de qué se trata? Jim.henderson 02:34, 17 de julio de 2007 (UTC) [ respuesta ]

Sí. DT2 es el segundo servicio digital dentro de un canal de RF físico. Por tanto, debería especificarse en el PSIP de la estación, que se describe en ATSC A/65C. -Dawn McGatney 69.139.231.9 (discusión) 10:17, 22 de abril de 2008 (UTC) [ respuesta ]

¿Por qué ATSC no funciona en vehículos en movimiento?

El artículo no explica, y creo que debería explicar POR QUÉ, en lugar de simplemente decir "no funciona". - Theaveng 19:57, 26 de septiembre de 2007 (UTC) [ respuesta ]

Debido a la necesidad de que un receptor ATSC muestree la señal transmitida en momentos muy precisos, el receptor digital no puede estar en movimiento; el movimiento provocaría un ligero cambio en la sincronización de la señal en el receptor debido al efecto Doppler; esto haría imposible el muestreo preciso de una señal 8-VBS. El 8-VBS mejorado o E8-VBS busca superar esta limitación transmitiendo una señal más robusta a una velocidad de datos más baja. -Dawn McGatney 69.139.231.9 (discusión) 10:21, 22 de abril de 2008 (UTC) [ respuesta ]

HDTV y SDTV

El artículo toca brevemente algo interesante pero no lo explica:

Si ATSC pudiera cambiar dinámicamente sus modos de corrección de errores, velocidades de código, modo entrelazador y aleatorizador, la señal podría ser más robusta incluso si la modulación en sí no cambiara. También carece de una verdadera modulación jerárquica, lo que permite recibir la parte SDTV de una señal HDTV incluso en áreas marginales donde la intensidad de la señal es baja.

¿Esto implica que se envía una transmisión SDTV con cada transmisión HDTV? ¿Cuáles son las características de estos feeds "SDTV"? ¿Son solo retransmisiones 7xx*480 4:3 de la señal analógica NTSC (o cuál sería la señal analógica NTSC, si todavía se transmitiera en 2009)? Varios televisores se venden como SDTV ATSC. ¿Utilizan la transmisión SDTV o simplemente reformatean la señal digital, sea cual sea su resolución, para que quepa en una pantalla NTSC de ~500 líneas? - Squiggleslash ( discusión ) 14:31, 12 de diciembre de 2007 (UTC) [ respuesta ]

E8-VBS permite transmitir simultáneamente una señal de velocidad de datos más robusta y más baja con una señal de velocidad de datos más alta; Si las cosas van "malas", un receptor E8-VSB configurado correctamente puede cambiar a la señal más robusta y de menor velocidad de datos. Además, un receptor E8-VSB puede utilizar la señal de velocidad de datos más baja para "aprender". -Dawn McGatney 69.139.231.9 (discusión) 10:31, 22 de abril de 2008 (UTC) [ respuesta ]

Enlace muerto (?)

La nota al pie 1 en línea simplemente va a la página de inicio de Businesswire, con un mensaje que dice "Debe iniciar sesión o registrarse antes de ver este comunicado de prensa". 86.132.141.139 ( charla ) 20:12, 27 de febrero de 2008 (UTC) [ respuesta ]

Pregunta sobre la transición

¿La transición ATSC hará que la FCC permita licencias de estaciones de radio FM en 87.5~87.9? Debido a que no habrá audio de TV analógica desde el canal 6 en 87.7 después de 2009, tal vez sería una buena idea... -- DaniAmaranth ( discusión ) 12:28, 8 de junio de 2008 (UTC) [ respuesta ]

Comparación (señal robusta)

Cuando se agregó originalmente, este comentario decía que el modo de transmisión ATSC es una "forma de onda robusta". La palabra "forma de onda" se cambió más tarde a "señal", pero el verdadero problema está en qué hace exactamente que la forma de onda o señal ATSC sea robusta. Como se implementa comúnmente con modulación 8VSB, ATSC parece estar lejos de ser robusto en diversas condiciones en comparación con el antiguo estándar analógico NTSC, así como con otros estándares digitales. Bajo ATSC (con 8VSB), un espectador puede experimentar una pérdida de imagen grave o completa en condiciones de clima húmedo o de viento leve, cuando las imágenes de transmisiones analógicas NTSC experimentan sólo una ligera degradación. Esta afirmación necesita justificación, especialmente a la luz de la comparación con estándares analógicos más antiguos, que deberían discutirse. —Comentario anterior sin firmar agregado por 140.142.183.42 (discusión) 04:31, 7 de enero de 2009 (UTC) [ respuesta ]

¿Análogo de baja potencia después del 17 de junio?

¿Se permitirá que las estaciones de televisión de baja potencia continúen con transmisiones analógicas después del 17 de junio? 204.210.242.157 ( charla ) 01:00, 7 de febrero de 2009 (UTC) [ respuesta ]

Sí. También clase "A" y traductores. -Dawn McGatney, 15 de abril de 2009.

¿Corea del Norte adopta ATSC?

Aunque me desconcierta la mención de Corea del Norte en la sección ATSC, ¿alguien tiene una fuente de la estación de propaganda de Corea del Norte destinada a que Corea del Sur se convierta a ese estándar? -- Daniel Blanchette 06:50, 15 de noviembre de 2009 (UTC) [ respuesta ]

1080p60

El estándar fue modificado en 2008 para incluir señales de 1080p50 y 1080p60. Alguien actualice la tabla de resoluciones en consecuencia a partir de la especificación modificada. -- 188.123.237.4 ( charla ) 18:14, 26 de abril de 2010 (UTC) [ respuesta ]

Sección "TP"

Solía ​​ser sobre ".ts", una extensión común. Cuestiono la validez de las referencias a ".tp". Cuestiono la eliminación (y reemplazo) de la sección ".ts". ¿Por qué se hizo eso? ¿Quién lo revisó?-- 134.130.183.101 ( discusión ) 11:37, 16 de diciembre de 2010 (UTC) [ respuesta ]

Nadie ha eliminado nada; de hecho, esta sección se agregó con esta edición ; Creo que es redundante, ya que el título de la sección Vídeo menciona específicamente el flujo de transporte MPEG . -- Dmitry ( discusióncontibs ) 20:41, 23 de diciembre de 2010 (UTC) [ respuesta ]

movimiento solicitado

La siguiente discusión es una discusión archivada sobre un movimiento solicitado . Por favor no lo modifique. Los comentarios posteriores deben realizarse en una nueva sección de la página de discusión. No se deben realizar más modificaciones en esta sección.

El resultado de la solicitud de movimiento fue: página movida . Vegaswikian ( discusión ) 06:01, 29 de agosto de 2011 (UTC) [ respuesta ]



ATSC (estándares)Estándares ATSC : aquí no se necesitan paréntesis. Este artículo trata sobre los estándares ATSC. Facts707 ( discusión ) 01:00, 22 de agosto de 2011 (UTC) [ respuesta ]

La discusión anterior se conserva como un archivo de una mudanza solicitada . Por favor no lo modifique. Los comentarios posteriores deben realizarse en una nueva sección de esta página de discusión. No se deben realizar más modificaciones en esta sección.

¿Historia de la sección ATSC?

¿Se necesita la sección Historia de ATSC? Como cuando se transmitieron por primera vez las señales ATSC, etc. Gooolog ( discusión ) 01:06, 16 de febrero de 2012 (UTC) [ respuesta ]

La citación no es realmente necesaria para la sentencia de pago de Zenith

No sé cuál es la forma correcta de modificar la cita, pero el artículo del MIT Tech citado en la frase anterior que describe el plan de soborno del MIT-Dolby también verifica que se hizo una propuesta para que también se sobornara a Zenith, para un posible descuento en pagos de regalías de patentes. Simplemente decir "Cita necesaria" parece implicar que no hay una fuente, pero el artículo vinculado analiza este tema (en la continuación del artículo en la página 15, no en la página 1). - Comentario anterior sin firmar agregado por 184.5.200.69 (discusión) 20:11, 24 de junio de 2012 (UTC) [ respuesta ]

Error en "MPEG-2"

La siguiente frase parece contener un error:

La especificación ATSC también permite secuencias MPEG-2 de 1080p30 y 1080p24, aunque no se utilizan en la práctica porque las emisoras quieren poder cambiar entre contenidos de 60 Hz (noticias, telenovelas) y 24 Hz (horario de máxima audiencia) sin finalizar la transmisión. Secuencia MPEG-2.

¿Es contenido de 60 Hz y 48 Hz, o contenido de 30 Hz y 24 Hz? ¿O debería representarse en fps en lugar de Hz? 60 y 24 no tiene mucho sentido para MPEG-2. Además, el 60 parecería entrar en conflicto con la tabla anterior en la sección, que indica los valores en Hz que puede manejar una transmisión de 1080p; 60 Hz no es uno de esos. —/Mendaliv/ / Δ's / 17:05, 14 de junio de 2013 (UTC) [ respuesta ]

Estamos hablando de formatos de fuente progresivos de 24 y 30 fps, es decir, películas (o cámaras de cine digitales para programas de máxima audiencia), englobados en un formato entrelazado de 60 fps. Como dicen anteriormente, las emisoras prefieren convertir una fuente progresiva de 24 fps (películas de pantalla grande) a 1080i60 con la técnica pulldown de telecine#2:3 (por lo tanto, una referencia a '60 Hz') en lugar de usar directamente el formato 1080p24 en el flujo de transporte y vuelva a cambiar a 1080i60 según sea necesario. Y la fuente progresiva de 30 fps (programas de televisión) se integra perfectamente en un flujo de transporte estándar 1080i60 utilizando la técnica 1080sf30 (cuadro segmentado progresivo). Reformulé la oración anterior para incluir esta explicación. -- Dmitry ( charlacontibs ) 08:30, 16 de junio de 2013 (UTC) [ respuesta ]
Además, debe considerar el párrafo anterior a la cita anterior, que dice que algunas estaciones de TV en realidad usan 1080p24 (o 1080p30) como formato de codificación en su flujo de transporte 1080i60. -- Dmitry ( discusióncontibs ) 08:40, 16 de junio de 2013 (UTC) [ respuesta ]

¿Surinam es ATSC o DVB?

Según el mapa, Surinam está utilizando el estándar DVB y no el estándar ATSC, sin embargo, este artículo menciona que está cambiando al estándar ATSC. Entonces, ¿a cuál se está cambiando realmente? Sion8 ( discusión ) 05:35, 21 de agosto de 2015 (UTC) [ respuesta ]

Enlaces externos modificados

Hola compañeros wikipedistas,

Acabo de modificar 8 enlaces externos sobre los estándares ATSC . Tómese un momento para revisar mi edición. Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página por completo, visite estas sencillas preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:

Cuando haya terminado de revisar mis cambios, establezca el parámetro marcado a continuación en verdadero o no informe a otros (documentación en

{{Sourcecheck}}).

Este mensaje se publicó antes de febrero de 2018. Después de febrero de 2018 , InternetArchiveBot ya no genera ni supervisa las secciones de la página de discusión "Enlaces externos modificados" . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación periódica utilizando las instrucciones de la herramienta de archivo a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si quieren ordenar las páginas de discusión, pero consulte el RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}

Saludos.— InternetArchiveBot ( Informe de error ) 11:35, 1 de octubre de 2016 (UTC) [ respuesta ]

Declaración dudosa en la sección "MPEG-2"

El primer párrafo de la sección MPEG-2 establece que el tamaño del fotograma (antes de la visualización) es 1920x1088, en lugar del 1920x1080 mostrado, porque tiene que ser divisible por 16. Pero 1920x1080 _es_ divisible por 16. ¿Hay algún error en alguna parte? ?

BMJ-pdx ( discusión ) 00:38, 12 de mayo de 2017 (UTC) [ respuesta ]

Tienes razón en que esto no se redactó correctamente. MPEG-2 requiere que la divisibilidad por 16 se aplique al ancho y al alto por separado, no al producto del ancho por el alto. 1920x1080 (es decir, 2073600) es divisible por 16, al igual que 1920, pero 1080 no. 1080 dividido por 16 es 67,5, por lo que no es divisible por 16 y es por eso que se completa hasta 1088. Mulligatawny ( discusión ) 00:47, 12 de mayo de 2017 (UTC) [ respuesta ]

Precisión cuestionada de H.264/MPEG-4 AVC

El párrafo y la tabla que lo siguen inmediatamente afirman que los niveles 3 y 3.2 están permitidos, pero level_idcen la fuente proporcionada solo se habla 31de 40y 42.

La Parte 2 dice para level_idc: Los valores serán los definidos en la Tabla 6.3 de ATSC A/72 Parte 1 . Sin embargo, el último es el cuadro 6.1 del documento. Insinúa que un valor de 31sería el nivel 3.1, mientras que 40es el nivel 4 y 42el nivel 4.2 respectivamente.

¿De dónde vienen los otros números de niveles? Por ejemplo, ¿es exacto que 1280 × 720 admita el nivel 3.2 en el estándar, mientras que el documento al que se hace referencia solo 40lo menciona? 84.250.0.210 ( charla ) 20:17, 6 de junio de 2017 (UTC) [ respuesta ]

Enlaces externos modificados

Hola compañeros wikipedistas,

Acabo de modificar 2 enlaces externos sobre los estándares ATSC . Tómese un momento para revisar mi edición. Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página por completo, visite estas sencillas preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:

Cuando haya terminado de revisar mis cambios, puede seguir las instrucciones de la plantilla a continuación para solucionar cualquier problema con las URL.

Este mensaje se publicó antes de febrero de 2018. Después de febrero de 2018 , InternetArchiveBot ya no genera ni supervisa las secciones de la página de discusión "Enlaces externos modificados" . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación periódica utilizando las instrucciones de la herramienta de archivo a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si quieren ordenar las páginas de discusión, pero consulte el RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}

Saludos.— InternetArchiveBot ( Informe de error ) 06:54, 24 de junio de 2017 (UTC) [ respuesta ]

La afirmación en la subsección MPEG-2 es claramente incorrecta (por simple aritmética)

Se afirma que los formatos de 1080 y 720 líneas tienen el mismo número de muestras por segundo ya que "1980*1080*30 es igual a 1280*720*60". Pero esta afirmación es claramente incorrecta; una simple verificación muestra que 1980*1080*30= 64152000 , mientras que 1280*720*60= 55296000 . No sé si simplemente hay un error tipográfico en alguna parte o si este concepto es completamente incorrecto. (Tenga en cuenta también que la afirmación sigue siendo incorrecta si se reemplaza 1980 por 1920).