We are not allowed to post links to other forums but this is the post I've seen. Don't ask me what it means or how to fix as I don't have a clue lol
####################################################################
this is not my work by Hackman Well it's been a few days since the audio problems were introduced on Virgin Media and so far we've have only crappy suggestions
such as editing the PID's manually, hacks to ABM with a 'bodge' to replace scanned results with hard coded data... but so far nobody
has explained how original boxes seem unaffected or attempted to understand what the root cause is, knowledge which would required to fix the issue.
To understand the issue we need to first understand some basics.
Using a program like TSReader you can tune to the TP of the affected stream. In this post I will use TSID:28. The frequency this is
on will vary area by area but once found the channels & data will be the same. This transponder contains 2 services of interest:
- SyFy HD
- TCM HD
The reason these are interesting is they both show slightly different symptoms.
- SyFy HD has no audio at all
- TCM HD has audio, but with narrative.
What is happening is the E2 boxes are seeing the narrative audio tracks as normal (which are regular MPEG2 audio), but not seeing the regular audio which is broadcast in AC3 format.
SyFy HD only has a single AC3 audio track, so with this now 'invisible' to E2, we get no sound!
TCM HD has 2 tracks, the AC3 audio track that is 'invisible' to E2, and a regular MPEG2 audio narrative one that it can see - which it
then selects as default.
We want to look at the AC3 one, which as you can see is clearly listed - but E2 boxes don't see it (hence 'invisible')
Code:
Elementary Stream PID 131 (0x0083) Dolby AC3 Audio
Descriptor: AC3 Audio Descriptor
Flags: AC3 Type: True BSID: True Main ID: False ASVC: False
AC3 Type: 0
BSID: 10
Descriptor: ISO639 Language Descriptor
Language: eng
Audio type: undefined
Descriptor: Maximum Bitrate Descriptor
Maximum bitrate: 48000 bytes per second
Descriptor: Stream Identifier Descriptor
03
So lets look at our raw hex ES info entry:
Code:
06 Stream Type: 0x06 Dolby AC3 Audio
E1 AF PID: 431 (0x01AF)
F0 12 ES_info_length
6A Tag 0x6A: AC-3_descriptor
02 Tag Length: 0x02
CF 00
0A Tag: 0x0A: ISO_639_LANGUAGE_DESCRIPTOR
04 Tag Length: 0x04
65 6E 67 ISO_639_language_descriptor ('eng')
00
0E Tag: 0x0E - Maximum Bitrate Indicator
03 Tag Length: 0x03
C0 03 C0
52 Tag: 0x52: Stream Identifier Descriptor
01 Tag Length: 0x01
03 Stream Identifier Descriptor
This ES_Info is made up of a number of tags, 0x06 been the initial tag, and some sub-tags 0x6A, 0x0A, 0x52
Now this is where the problem is: The tag 0x6A is malformed.
It specifies a data length of 0x02, which we see the 2 bytes 0xCF and 0x0010
If we use the DVB specification to look at the structure of the AC3 descriptor:
Code:
AC-3_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
component_type_flag 1 bslbf
bsid_flag 1 bslbf
mainid_flag 1 bslbf
asvc_flag 1 bslbf
reserved_flags 4 bslbf
if (component_type_flag == 1) { 8 uimsbf
component_type
}
if (bsid_flag == 1){ 8 uimsbf
bsid
}
if (mainid_flag == 1){ 8 uimsbf
mainid
}
if (asvc_flag == 1){ 8 uimsbf
asvc
}
for(i=0;i<N;i++){ 8 uimsbf
additional_info_byte
}
}
We can see if starts with a tag (0x6A) and length (0x02 in our case)
The next byte that follows this is what is a byte that contains a series of flag.
The lower 4 bits are all reserved (set to 1) so this leaves the upper 4 bits which are defined as follows:
Code:
component_type_flag: This 1-bit field is mandatory. It should be set to "1" to include the optional component_type field in the descriptor.
bsid_flag: This 1-bit field is mandatory. It should be set to "1" to include the optional bsid field in the descriptor.
mainid_flag: This 1-bit field is mandatory. It should be set to "1" to include the optional mainid field in the descriptor.
asvc_flag: This 1-bit field is mandatory. It should be set to "1" to include the optional asvc field in the descriptor.
So for each bit that is set to 1, and extra byte must be included/processed
The upper 4 bits of 0xCF in binary are 1100, so this specifies that the the component_type and bsid are set, requiring 2 more data bytes after the 0xCF - but we only have 1 extra byte remaining (a value of 0x00)
So what happens?
Well the 0x00 gets interpreted as the component_type field, and the next byte after is is 0x0A. This is the start of the next descriptor, this gets interpreted as the bsid field.
In TSReader we see this:
Code:
Flags: AC3 Type: True BSID: True Main ID: False ASVC: False
AC3 Type: 0
BSID: 10
AC3 Type is the component_type field, and BSID is 10 in decimal, which in hex is 0x0A (that tag byte of the following descriptor).
At this point we have overflowed the end of the tag 0x6A... so what happens next?
Well this is down to the parser code. After processing the tag 0x6A, how do we locate the next tag:
2 ways:
1. Assume the next tag starts after the end of the first tag. This is what should happen in normal case.
2. Take the start of the current tag on, and add '2 + the value of <TAG DATA LENGTH>.
If the parser code follows option 1 - then it will start trying to parse the next tag 1 byte to late, and will interpret it as nonsense, and end up discarding it - which is what I suspect E2 is doing.
If the parser code follows option 2 - then the next tag will start at the correct position. The byte 0x0A will be 're-used', as it's both the data at the end of the last tag and the tag byte of the next descriptor. The remaining tags which specify the language ('eng') etc. will be processed correctly.
This is probably accidental rather than by design. My guess is the bsid bit it not supposed to be set... but since it is this is what happens.
I refer to these tags as 'overlapped' tags. I guess E2 cannot handle these overlapped tags correctly, where as official boxes can.
There are some simple code hacks that could allow the parser of E2 to code with these malformed overlapped tags correctly, or they could do a propper job. Thats assuming they do anything at all.
####################################################################
This is a version of the spec.
Table D.2: AC-3 descriptor syntax
This is the important table - this specifies the format of the AC3 Descriptor Tag 0x6A that VM have malformed.
A quick and dirty fix to get the tags to process correctly again would be to add a hack into the part that processes this specific tag:
Code:
if (descriptor_length == 2 && bsid_flag == 1)
{
bsid_flag = 0; // Clear bsid to prevent it looking for a 3rd data byte that isn't there.
}
http://www.etsi.org/deliver/etsi_en/...68v011101p.pdf(this is not my work by Hackman)
####################################################################
There parser assumes the tags don't overlap and the next one starts directly after the end of the first one. So processing the first one should leave them pointing at the start of the second one. With overlapped/malformed tags this is no longer case.
The pointer to the start of the 'next' tag should be calculated by adding the size of the 'advertised' length onto the starts 'current tag'.
####################################################################
As said I don't have a clue what it means but hopefully Image devs do and they manage to fix it.
