Hi! Sven Over wrote:
Unfortunately, the xine MPEG demuxer only takes 2 bits of that field in the pack header into account. Therefore, if there are 5 padding bytes in the pack header, xine accounts it as only 1 byte. Sorry, but this is plain wrong. I quoted the corresponding line of the source code in my bug report. There is no doubt that this field of the pack header consists of three bits.
Good to know. I didn't run into that problem (yet), maybe because I write out ordinary program streams. But I fixed my local copy of xine-lib anyway :)
Padding the pack header seems to be a rarely-used option, however. And there's also another way: pad the PES packet header. It may contain up to 32 stuffing bytes (0xff) just in front of the payload, controlled by the PES_header_data_length field (the byte at offset 8). As far as I can tell from the source, xine-lib will get that one right.
On the other hand, padding isn't required at all. A properly written decoder should detect a sync word even if it crosses a PES packet boundary, and attribute it to the correct packet (the one the first byte occurred in).
-- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ DVBCUT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dvbcut-user
