GNOME Bugzilla – Bug 736003
mpegts : How to determine the same section
Last modified: 2014-12-19 08:20:36 UTC
As many sections , we can use subtable_extension, version_number, last_section_number and section_number to check whether this section was seen. but some sections , such as STT, ETT in ATSC , we can't use this way. they have the same value of judge items, and different contents. i want to add crc32 as new judge item to determine the same section , but i'm worry that it can't determine completely with above judge items. there maybe still many different sections as the same one and are ignored. is there better way to determine the same section?
This sounds very wrong. Unless there is a noticeable stream change (you switched channels or files, in which case the packetizer should potentially expect new sections), a section with all these following identifiers identical should represent the same content. If there is a change, then there should be a different version_number (otherwise it *completely* beats the whole point of having that field). Furthermore, checking crc32 on *all* sections would be way too expensive, it should only be done on (potentially) new ones. Can you provide samples that better show this ? Or point to the ATSC specifications that indicate that version_number is not updated for new content in the same stream ?
STT has this issue obviously. ATSC Standard (A65/2013) page 24: table_id_extension – This 16-bit field shall be set to 0x0000. version_number – This 5-bit field shall have a value of zero. section_number – The value of this 8-bit field shall always be 0x00 (this table is only one section long). last_section_number – The value of this 8-bit field shall always be 0x00. every item should be set 0. so we can't judge whether the sections are the same.
ETT also has this issue, but maybe only occured in Korea or the United States. ATSC Standard (A65/2013) page 45: ETT_table_id_extension - each ETT instance when the tables appear in transport stream packets with common PID values. The ETT’s table_id_extension shall be set to a value such that separate ETT instances appearing in transport stream packets with common PID values have a unique ETT_table_id_extension value(13). note (13): Broadcasters in Korea are advised that some deployed receivers may not operate correctly with a non-zero value for this field. Some such receivers may have been deployed in the United States. as mentioned above, every ETT section has a unique ETT_table_id_extension value, but it still is zero in Korea and the United States. so there maybe the following situation, different ETT sections have the same ETT_table_id_extension value with 0. of cause other judge items are also the same.
(In reply to comment #1) > Furthermore, checking crc32 on *all* sections would be way too expensive, it > should only be done on (potentially) new ones. > i won't check crc32 on all sections, only compare with continuous two sections having same section_number. it will not be spent too much. although even using crc32 comparing still can't guarantee that sections having different contents are not ignored, but it will let percentage of ignored section reduce. I will try to use this method to modify this issue.
In regards to STT, despite the fact that for some reason they decided to use a "long" section instead of a short one and there's no sane update indicator, it seems to me as though you only need one anyway. It essentially gives you the master system time reference (in GMT time). You can then use that to show proper time on your system. It only seems to be used for user reference. So I think it's totally fine that you only have that section parsed once. It serves as a reference time, you only need it once. Note that if you switch channel/streams, the packetizer will be resetted and it will re-detect that STT. In regards to ETT, just using one table_id_extension (ab-using the generic section subtable field) is totally fine. The version_number field is present, and if updated on changes you will get updates. Does that make sense ? If so this bug can be closed.
No answer for more than 3 months, closing. Please re-open with more information if you think more needs to be done here, thanks! Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Indeed, we can close it. Note that in the meantime, we now reset section parsers on various discontinuity information (from upstream), so that should mitigate even more potential issues.