AC3-ATSC

Report here any bugs you found
Post Reply
EnoSat
Posts: 32
Joined: Sat Jan 04, 2020 8:43 am
Location: Slovakia
Contact:

AC3-ATSC

Post by EnoSat »

If transponder use AC3-ATSC sound , not work sound. But after manual set work.
Image
Image
https://mega.nz/#!ZY1zQQiR!_K197mgLz34F ... u17Fmsgb3g
Televes H30 FLEX
Gibertini OP100L /85E-53W/
WaveFrontier T90 /39E-36E-31E-28E-26E-23E-19E-16E-13E-9E-7E-5E-2E-1W-4W-30W/
TBS-5925 , TBS-5880 , TBS-5220 , Mutant HD51 , Ineos ZX4 , Coolstream Zee2 , Dreambox 900UHD/7020HD/500HD
User avatar
Mr. Orbita
Posts: 70
Joined: Fri Jan 03, 2020 11:05 pm
Location: Warsaw
Contact:

Re: AC3-ATSC

Post by Mr. Orbita »

In stream there is no AC3 descriptor (0x6A) and also no registration descriptor (0x05). In DVB everything above 0x7F is a private (user defined) stream_type. In theory AltDVB could assume that always stream_type 0x81 is ATSC AC3, but that's risky if 0x81 will be used for something else, with proper descriptor, as DVB not defines this that way as ATSC does. Broadcaster - if using DVB - should use proper DVB descriptors, eg 0x6A or 0x05 - in that case AltDVB will detect AC3 on 0x81 stream_type and it was tested & confirmed ;)

It is open how to treat such case, without any descriptors...

Maybe some setting in Scanner to always treat 0x81 and 0x87 stream_types as ATSC AC3/E-AC3 and eventually user will decide is he taking the risk of potential drawbacks of such decision, just like for SDT 0x46 tables?

Thanks for reporting and TS sample - very helpful ;)
EnoSat
Posts: 32
Joined: Sat Jan 04, 2020 8:43 am
Location: Slovakia
Contact:

Re: AC3-ATSC

Post by EnoSat »

ATSC A/52-2018
E-AC-3 bit streams shall be identified with a stream_type value of 0x87 when transmitted as PES streams conforming to ATSC-published standards. Note that other standards development organizations may choose other stream_type values; (e.g., DVB, as documented in ETSI TS 101 154 [8], chose 0x06).
Televes H30 FLEX
Gibertini OP100L /85E-53W/
WaveFrontier T90 /39E-36E-31E-28E-26E-23E-19E-16E-13E-9E-7E-5E-2E-1W-4W-30W/
TBS-5925 , TBS-5880 , TBS-5220 , Mutant HD51 , Ineos ZX4 , Coolstream Zee2 , Dreambox 900UHD/7020HD/500HD
User avatar
Mr. Orbita
Posts: 70
Joined: Fri Jan 03, 2020 11:05 pm
Location: Warsaw
Contact:

Re: AC3-ATSC

Post by Mr. Orbita »

Thanks to document from you I see some proper and safe way to handle this, lowering any risk to damage detection of other ES PID's. The table A4.1 at page 99 (or 8.1 at page 17 from here: https://www.atsc.org/wp-content/uploads ... 6-2013.pdf) indicates AC-3 ATSC descriptor, that can help to distinguish it properly, not only by stream_type.

TS from you has got for example for PANICO HD descryptor 0x81 connected to 0x81 stream_type, which has got value:
08 20 03 FF 0F - first audio track
08 20 03 FF 2F - second audio track

By parsing them we will get (if I didn't made any mistake :roll: ):

Code: Select all

0x81	descriptor_tag:		0x81
0x05	descriptor_length:	0x05
0x08	sample_rate_code:	000 (48 kHz)
	bsid:			01000 (OK for 0x81)
0x20	bit_rate_code:		001000 (128 kbit/s, exact)
	surround_mode:		00 (not indicated)
0x03	bsmod:			000 (complete main)
	num_channels:		0001 (1/0)
	full_svc:		1 (full)
0xFF	langcod:		0xFF (deprecated, OK)
bsmod<2
0x0F	mainid:			000 (unique value, 0)
	priority:		01 (primary audio)
	reserved:		111 (OK)
For second audio
0x2F	mainid:			001 (unique value, 1)
	priority:		01 (primary audio)
	reserved:		111 (OK)
Seems that descriptor is shortened to 5 bytes and has got no textlen and language flags further.

At page 244 from your document there's an E-AC3 descriptor aswell, tag 0xCC.

Existance of these descriptors could indicate properly ATSC audio, but I feel that these descriptors are way too complicated. Maybe only checking existence of 0x81 and 0xCC descriptors if stream_type is 0x81 or 0x87, without really parsing them would be enough... (eventually language information would be missing, but on this channels it is missing anyway ;) )

A tricky case ;)

Eventually to be considered by @altxro how to treat this ;) Maybe our investigations will help ;) Thanks @EnoSat ;)

Some comment/thoughts on this:

DVB and ATSC have different ways of signaling the same things, in some cases even excluding each other. Supporting all ATSC signaling would surely damage detection of DVB streams. That transmission is DVB, but using ATSC signaling. Should be using DVB or eventually add DVB descriptor 0x6A or 0x05, which AltDVB is accepting too. 0x81 and 0x87 are not used for AC3/E-AC3 in DVB. AltDVB already has got a workaround in case of stream_type 0x81 and 0x87, but only if there are 0x7A/0x6A or 0x05 descriptors with proper values. This can be seen at Hot Bird on Discovery Showcase HD from 12,130 H. There's 0x81 stream_type, but Nova has correctly added 0x6A descriptor and AltDVB respect this :)

Image

Without descriptors, when using only stream_type, it gives a risk of many false detections of non-existant audio on some data transmissions.

Probably the reason for missing DVB descriptors on that 47,5°W is that's some direct feed for terrestrial transmitters and broadcaster decided to keep ATSC structure, to be able to copy easily stream straight to ATSC transmitter. I feel that AltDVB treating this case basically fine - transmission is DVB, signaling is non DVB and without DVB descriptors, which is wrong on broadcasters side, even if it is done on purpose.

There are plenty of examples, where broadcasters signaling something wrong, eg. Oman TV HD from Hot Bird (12,654 H) has got audio MPEG, but AltDVB show AC3 and... that's correct, because Oman TV HD broadcasting incorrectly AC3 descriptor 0x6A, where it should not ;)

I think that in general we shouldn't try to fix mistakes and search for workarounds for cases, when something is broadcasted incorrectly. In the case of 47,5°W broadcast - problem is ATSC signaling in DVB stream instead of DVB one. This would lead to need of support of more ATSC signaling, if other broadcaster will use something other from ATSC. Here we have only audio issue, but ATSC has got much more differencies in compare to DVB.

I would say it is even good to see such cases, that helps to do some brief analyze, where if AltDVB would automatically detect this, we wouldn't know about that :)

Anyway I think that there is a way to improve situation for this special case ;)
Post Reply