#7 TS sync enhancement

[Tom Maughan]

The current method for syncing to the start of the packet results in a lot of spurious locks and lots of duff packets with the "Wrong SyncByte or packet length mismatch (= no TS)" messages.

Searching for 0x47 on its own isn't quite enough. A better way is to look for 0x47 and then checking the next byte has bit 6 set.

See attached file, ts_SyncRead now uses a two stage found process to locate the start of the packet.

It locks on to the TS_Sync nicely now, no more skipped bytes, no more wrong syncbyte messages.

[Tom Maughan]

[rainer scherg]

Logged In: YES
user_id=115734
Originator: NO

Bit 6 of the next byte following sync x047 is described as "transport_priority".
According to ISO standard 13818-1 this could be [0..1].

Please help me here, if I am getting something wrong.

>>
sync_byte 8 bslbf
transport_error_indicator 1 bslbf
payload_unit_start_indicator 1 bslbf
transport_priority 1 bslbf
PID 13 uimsbf

[Tom Maughan]

Checks for correct packet length when using stdin

[Tom Maughan]

Logged In: YES
user_id=369419
Originator: YES

You are correct, just had a look at a live feed from a satellite at home and they set priority to 0 except on the PAT. Everything we deal with at work has it set to 1 for all PIDs. Should have checked a domestic feed before submitting, sorry!

It actually appears the problem is only when using stdin. Take the TS from /dev/dvb/adapterX and its fine, cat /dev/dvb/adapterX/dvr0 to a file and use dvbsnoop -if file and its fine but if I pipe the stream into stdin using "-if -" it gets lots of spurious locks and starts skipping bytes.

Found the problem, when using stdin its not always reading a full TS length which is causing the errors.

I've added a check to see if n1 is the correct number of bytes, if not read more from the file until n1 is the correct length. You may want to make this conditional on the input file being stdin.
File Added: dmx_ts-stdin.c