| Guild of Copy Editors | |||
|
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
This subject should be included (or linked) in the subset under Broadcast Engineering on the list along side EIA-608, CEA-608. /info/en/?search=Category:Broadcast_engineering -Evan — Preceding unsigned comment added by 156.33.232.173 ( talk) 22:56, 27 April 2015 (UTC)
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)
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)
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
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)
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)
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)
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)
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)
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)
| Guild of Copy Editors | |||
|
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
This subject should be included (or linked) in the subset under Broadcast Engineering on the list along side EIA-608, CEA-608. /info/en/?search=Category:Broadcast_engineering -Evan — Preceding unsigned comment added by 156.33.232.173 ( talk) 22:56, 27 April 2015 (UTC)
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)
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)
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
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)
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)
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)
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)
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)
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)