1

i have a project and i have to write a ts file parser. The parser should read a ts file and output some data from the headers of each packet of the file. Two of the outputs that i have to print are, if there are sync errors(and how many) and the number continuity counter errors.

About the sync error first. I know that the first byte of the packet refers to the sync byte. So, we have a sync error, if the sync byte of the packet doesn't have the 0x47 value as it should? So if there are 100 packets in the file, and 30 sync bytes are "bad" there are 30 sync errors?

About the continuity counter error, i would like someone to explain how to find if there is a continuity error in simple words, as the mpeg2 standard that i read did not help much. Thank you

jmfel
  • 43
  • 2
  • 9

2 Answers2

5

A sync byte error is when the first byte of a TS packet does not contain the value 0x47. In this context it may be wise to support different TS packet lengths. Usually a TS packet is 188 bytes long, but you may encounter different packet lengths, e.g. if Reed-Solomon error protection has been added a TS packet is 204 bytes long.
The ISO 13818-1 standard is pretty clear and unambiguous about what a continuity count (CC) error is. In simple terms, each TS packet contains a 13 bit PID (packet identifier) field and a 4 bit CC (continuity count) field. Consecutive packets of the same PID must contain incrementing CC values (modulo 16, so after CC = 15 follows CC = 0) if the packet contains payload (which can be determined from the adaptation_field_control flags). Thus you will need to track the CC values for each PID separately. If there is a gap in the CC values, e.g. CC = 7 follows after CC = 5 this is a CC error. Special attention must be given to repeated CC values. A CC value may be repeated once, e.g. CC = 5 in two consecutive TS packets (with same PID). If a CC value is repeated more than twice this also constitutes a CC error.
Note that null packets (PID = 0x1FFF = 8191) do not contribute to CC errors, since the value of their CC field is undefined (the standard allows arbitrary CC values in the case of null packets).
Another exception is when the discontinuity_indicator flag is set, then the CC value may change to an arbitrary value and this does not count as a CC error event.

You may want to take a look at ETSI ETR 290, which defines some measurement guidelines for DVB systems. Among others there are some hints on how to count CC errors.

andrsmllr
  • 1,231
  • 18
  • 39
0

i experienced mpeg system streams where gaps between ts-packets are present. It's worth noticing that the gaps are of a very particular form, all gaps are stuffed by bytes equal to the current gap length. For example if a gap has the length equal to 4 the following pattern is present 04 04 04 04 47 ... VLC player plays such streams without reported or observed errors. Strictly speaking this is a sync error.

if you take a compliant mpeg system stream and insert say the following byte pattern '04 04 04 04' between two successive ts-packets even ffmpeg/ffplay does not recognize this stuffing data as a sync-error, use 'ffmpeg -i -f null /dev/null'

ffmpeg has inbuilt FEC autodetect (FEC patterns can be attached at the end of some or all ts-packets). Therefore ffmpeg skips stuffing data between ts-packets unless the length of stuffing data is smaller a pre-defined threshold.

Shevach Riabtsev
  • 357
  • 2
  • 7