Talk:CTA-708

This article was copy edited by a member of the Guild of Copy Editors.Guild of Copy EditorsWikipedia:WikiProject Guild of Copy EditorsTemplate:WikiProject Guild of Copy EditorsGuild of Copy Editors articles

Television: Broadcasting Low‑importance

	Television portal This article is within the scope of WikiProject Television, a collaborative effort to develop and improve Wikipedia articles about television programs. If you would like to participate, please visit the project page where you can join the discussion. To improve this article, please refer to the style guidelines for the type of work.TelevisionWikipedia:WikiProject TelevisionTemplate:WikiProject Televisiontelevision articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by the Broadcast engineering and technology task force.

Broadcast Engineering

This subject should be included (or linked) in the subset under Broadcast Engineering on the list along side EIA-608, CEA-608. https://en.wikipedia.org/wiki/Category:Broadcast_engineering -Evan — Preceding unsigned comment added by 156.33.232.173 (talk) 22:56, 27 April 2015 (UTC)[reply]

Untitled

There are many details on this page, some of which have been reported to me to be badly dated and wrong. We are investigating the best way to correct this page. Please contact me if you have any commentary on an update process.

Adam Goldberg Chair, CEA R4.3 (the source of CEA-708)

Just go ahead and make the changes, Adam. – joeclark (talk) 21:50, 16 January 2009 (UTC)[reply]

I tried contacting Adam on his talk page but got no response. I wrote the original article after reading the original EIA standard and implementing it, but without it in my hands to avoid any inadvertent copyright violations. This of course allowed any of my misunderstandings of the standard to be reflected in the final page. I should also point out that there were many areas of at least the original standard that were unclear. Where possible I based my interpretation of those aspect on actual broadcast captions, which of course could also be incorrect when the standard itself is unclear. Since then I know there have been revisions to the standard, but I have not seen those. Zenyu (talk) 18:19, 8 August 2009 (UTC)[reply]

Sorry to have not responded to the message from ... 2009. Would you believe I just read it? Adamgoldberg (talk) 12:53, 15 September 2021 (UTC)[reply]

In the 'User Picture Data' section, the 'user_data_start_code' is not a 32-bit value. I believe it may be missing a zero. - Sandinog (talk) 03:29, 12 June 2010 (UTC)[reply]

On the other hand, the creation of this page, effectively from memory, seem little short of monumental, and I don't mean to sound nit-picking; it is, overall, a real achievement. In an aside to the CEA, if anyone's listening, how do they expect to progress the technology by keeping it so tightly in the grip of the people, however clever, who first conceived it, and using the copyright laws to secret it away from the wider community? As an organization funded by the consumer electronics industry, their members would be far better served by having these standards copylefted instead of copyrighted. Sandinog (talk) 03:53, 12 June 2010 (UTC)[reply]

h.264 ambiguities

I'm not sure how to fix this... there is a significant ambiguity in the definition of the h.264 SEI unit. It is actually an array of payloads of various types and you can add another payloadType after payloadSize bytes. This is very important both for parsing and generation.

For parsing, the user_data_registered_itu_t_t35 payload containing the cc_data structure does not have to be the first one. I've seen encoders (MainConcept's is a good example) that output multiple in a single SEI unit with other payload types first.

This is only an issue for generation because you must terminate the sequence with an 0x80 (a sync byte that's also an invalid payloadType) prior to the next start code. VLC, notably, will fail to render captions if the 0x80 isn't there.

The payloadSize refers only to the size of the one entry in the array so you can locate the next by jumping past that many bytes if payloadType isn't user_data_registered_itu_t_t35 (4), itu_t_t35_country_code isn't US (181), itu_t_t35_provider_code isn't ATSC (49) or user_data_type_code isn't cc_data (3).

Also, It's not that common but payloadType, payloadSize and itu_t_t35_country_code may all be multiple bytes. You keep reading and adding the byte values up to and including the first byte that is less than 0xFF. For example, 256 would be FF 01, 511 would be FF FF 01 and so on. Protocol6 (talk) 00:39, 2 December 2012 (UTC)[reply]

Reply

According to ITU-R Rec. H.264 - section 7.3.2.3, one SEI RBSP NAL unit should not contain more than one SEI message for one SEI payload therefore if a encoder wants to insert multiple SEI payloads of different types, it should be inserting another SEI RBSP NAL unit after the last one. As multiple SEI RBSP in one NAL unit can cause decoding delays especially on re-syncing.

As stated this is a bad encoder practice, also the page is just a basic overview not a full specification.

Embedded captions should not need to exceed a payloadSize of 256 and in practice the payloadType should never need to go past 256 either. Especially since the MPEG practice of embedded extended user data in the video stream has never been a good one. As either a separate synchronized stream or using a container's metadata produces much better decoding results. Helmboy (talk) 03:37, 2 December 2012 (UTC)[reply]

Long on technical details, short on information useful to laypeople

The beginnings of support for Unicode imply support for captions in any writing system included in Unicode. As a person who is hard of hearing AND has studied several languages not natively written in Latin alphabets, this is fairly significant to me, and I trust to millions of hearing-handicapped people as well as billions of language learners all over the world. I think that for the majority of readers interested in the topic of closed captions, these broader implications are much more important than technical details. LADave (talk) 21:53, 9 December 2016 (UTC)[reply]

Dead link in the External links section

The link to the standard on the CEA website is dead. It forwards to the same url on cta.tech which doesn't work. On the cta.tech site I found https://www.cta.tech/Research-Standards/Standards-Listing.aspx which link to https://www.techstreet.com/standards/cta-708-e?product_id=1860354 not sure what to remplace the link with, either the official page but all standard are listed not just CEA-708, or the specific page but techstreet is just a reseller not directly related to the standard I believe. — Preceding unsigned comment added by 212.88.12.209 (talk) 20:30, 17 October 2017 (UTC)[reply]

The newest link is https://shop.cta.tech/products/digital-television-dtv-closed-captioning. Note that this is (and has been for a couple of years) free to download (you have to 'buy' it for $0.00). Adamgoldberg (talk) 12:54, 15 September 2021 (UTC)[reply]

"CEA" (and CEMA and EIA references) should be CTA

Several years ago, the Consumer Electronics Ass'n (CEA) renamed itself to the Consumer Technology Ass'n (CTA). Similarly, the standard was "re-designated" as CTA-708 (the current version is CTA-708-E).

This page should be renamed to "CTA-708", and CEA-708 should redirect to CTA-708 (as should EIA-708, which hasn't been the designation for ~20 years). See Consumer Technology Association Adamgoldberg (talk) 13:01, 15 September 2021 (UTC)[reply]

April 2023

Wikipedia is not an indiscriminate collection of information. As stated above, making a monkey copy out of some technical standard is not writing an encyclopedia article. All that dubious minutia doesn't tell a reader *why* any of it exists or the point of the activity in any way. Wikipedia is not a user's manual, textbook, or substitute for any technical standard. --Wtshymanski (talk) 01:35, 8 April 2023 (UTC)[reply]