MPEG2 transport stream PES stuffing bytes length

0
votes

I'm trying to write some code in C that will demux a MPEG2 transport stream into elementary streams. I'm using ffmpeg to compare the output that I'm generating from my code. The output stream from my program is basically bit-exact with ffmpeg except for one case. ffmpeg seems to be picking up the byte 0xff from the bitstream when it is at the start of the payload (after the end of the PES header and PES stuffing bytes), while I'm excluding it as a PES stuffing byte.

My question is this: Is the length of the stuffing byte(0xff) in the PES packet variable or is it encoded in the PES header as well?

note: The way I'm reading the payload data from the PES packet is I basically skip all the initial 0xff until I hit a byte that is not 0xff and read till the end of the packet from there

1
cmpeg2-ts
It is a very technical question. To insure interoperability, the best solution is to strictly comply to the mpeg-system standard. The description on the bitstream is in the document ISO/IEC 13818-1, but I do not remember such details. - Alain Merigot

1 Answers

2
votes

H.222.0 (03/17) (Page 37, table 2-21) defines the length of the stuffing_byte sequence as calculated by means of PES_header_data_length, which is defined as (emphasis mine)

An 8-bit field specifying the total number of bytes occupied by the optional fields and any stuffing bytes contained in this PES packet header. The presence of optional fields is indicated in the byte that precedes the PES_header_data_length field.

Therefore, when you're reading the PES header, you take note of all the optional fields (for example various combinations of PTS_DTS_flags, ESCR_flag, ES_rate_flag, and all the other stuff) and subtract the length of these optional fields from the length declared in PES_header_data_length. Once you've processed all the optional fields and the remaining length n is still not zero, it means that there's still n stuffing bytes to read before the payload comes.