1.2.13 TS Mux emits spurious packets

[Paul Shirley]

1.2.13 using the TS Mux on UK Freeview seems to be throwing out packet streams with random contents and no connection to the recording programme, in the worst case adding 50% to the filesize.

This has symptoms suggesting tables aren't being cleared between recordings, in the following ProjectX dump I see 3 real PIDs (0x258,259,25a) and 3 bad ones (0x28A,28B,28C), as if a previous programme's PIDs are still active. I have a couple of spurious packets containing fragments of a PNG file, seems to be dumping uninitialised RAM into the bad packets.

Video:

PID: 0x258(#1)

Audio:

PID: 0x259(eng)(#2)

PID: 0x25A(eng)(#6)

Teletext:

n/a

Subpict.:

PID: 0x25B(eng_0x10_p1_a1 )



!> PID 0x0 (PAT) (0 #1) -> ignored

!> PID 0x28A (payload: 9C 8B DF 48 A7 B9 7E F1 ..) (6016 #33) -> ignored

!> PID 0x28B (payload: 0E 8B 78 C7 F8 FC 2F C4 ..) (7896 #43) -> ignored

!> PID 0x28A (payload: AC C2 5D 47 CE 88 97 6A ..) (11656 #63) -> ignored

!> PID 0x28B (payload: 5D 00 00 00 17 00 66 00 ..) (12596 #68) -> ignored

ok> PID 0x258 has PES-ID 0xE0 (MPEG Video) (14100 #76)

!> PID 0x28A (payload: 29 6A 94 A9 D4 48 8C 2B ..) (37976 #203) -> ignored

!> PID 0x28A (payload: 5A 25 48 C4 27 67 2C A7 ..) (44368 #237) -> ignored

!> PID 0x28A (payload: 43 C6 9B 3E B7 6E BB 81 ..) (53580 #286) -> ignored

!> PID 0x28A (payload: 15 60 47 7E BE 3A AF C5 ..) (73132 #390) -> ignored

ok> PID 0x25A has PES-ID 0xC1 (MPEG Audio) (90052 #480)

ok> PID 0x259 has PES-ID 0xC0 (MPEG Audio) (97196 #518)

!> PID 0x28C (payload: 31 09 CC 4F D0 2A CA D6 ..) (100956 #538) -> ignored

Packet found with PNG content

-----------------------------------------------------------------------------
ITV Lunchtime News and Weather_20080529_13301400.ts : Thu May 29 15:44:01 2008
-----------------------------------------------------------------------------
00000520 : 47 08 cb 1c 87 29 3f 0f 2f 09 14 ef |.fR.G....)?./...|
00000530 : 69 9c e7 f5 60 28 df 6a 5d 2d b8 1a 18 37 eb b1 |i...`(.j]-...7..|
00000540 : 01 e3 3e 65 67 fc bc b6 04 e3 af f4 1b ae 9c 27 |..>eg..........'|
00000550 : 52 ff 9f 08 ac 00 00 00 00 49 45 4e 44 ae 42 60 |R........IEND.B`|
00000560 : 82 42 49 4f 50 01 00 00 00 00 00 03 c4 04 41 41 |.BIOP.........AA|
00000570 : 42 4f 00 00 00 04 66 69 6c 00 00 08 00 00 00 00 |BO....fil.......|
00000580 : 00 00 03 a4 00 00 00 03 a8 00 00 03 a4 89 50 4e |..............PN|
00000590 : 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 01 |G........IHDR...|
000005a0 : 8c 00 00 00 10 08 03 00 00 00 32 34 b8 f4 00 00 |..........24....|
000005b0 : 00 1b 50 4c 54 45 f8 bf 24 cc 99 ff cc 66 66 ff |..PLTE..$....ff.|
000005c0 : ff ff 66 00 66 ff 33 00 00 99 66 00 99 ff ff ff |..f.f.3...f.....|
000005d0 : 00 96 2f 3d d2 00 00 00 01 74 52 4e 53 00 40 e6 |../=.....tRNS.@.|

This is happening on all 4 tuners (2x 7010i DVBT,Kworld 355U,Azurewave AD-TU200). Logs attached (don't see any problem though), if you need a full TS how big do you need the capture?

[sub]

In the past TS Mux recordings only contained PAT packets, (incorrect) PMT packets, and packets from one audio and one video stream.

The TS Mux recordings now record the PAT packets, PMT packets, and all packets from all streams assocated with the channel in the PMT. ie, it'd now record multiple audio streams if the channel has them, and any DVB Subtitles or Teletext information carried with the channel etc.

The packets you thought were bad, or bits of PNG files, were most likely parts of the DVB Subtitles for that channel.

[Paul Shirley]

I'm getting 1 video + 1 or 2 audio + the subtitle stream and these spurious packets. Unless gbpvr is capturing the EIT or MHEG streams there shouldn't be anything else associated with the programme to capture.

The files are noticeably larger than expected, this afternoon 2.3GB v 1.9GB I normally see on a daily recording. They're larger than from my other source (Humax 9200 TS downloads) containing the same expected streams and ProjectX doesn't believe these packets belong to the programme. I'm also seeing Media Player Classic crash on random seeks if it hits them.

[sub]

Unless gbpvr is capturing the EIT or MHEG streams there shouldn't be anything else associated with the programme to capture.

It'll capture whatever streams are associated with that channel. Not EIT, but possibly MHEG or other data streams if the broadcaster has linked them to the channel in the PMT (Program Map Table). As far as I can tell they're perfect duplicates of what the broadcaster transmits now, whereas they were very cut back .ts files in the past.

The change was made because some devices, like the popcorn hour didnt like streams being missing that were referred to in the PMT. This change also allows us to record the teletext and dvb subtitle streams that others have been asking for.

[Paul Shirley]

I'll have a dig around and try to work out if these are MHEG or something else recognisable.

[Paul Shirley]

Definitely looks like MHEG5 so just annoying, not a bug.

However its quite a serious overhead, I've just demuxed the V+A+A+sub out of a BBC1 33min recording and it shrunk from 1.44GB -> 1.15GB - around .5GB an hour! An option to simply discard streams by type would be nice, probably safe for most users, but not urgent. They're all marked as type 0x0b (Data Carousel I believe) in the PMT on my test file.