Standard AC3 component descriptor handling
Commit Message
I am currently working on making the switch from PES to TS
as the VDR recording format, that's why there are currently
no new versions of VDR.
However, since the German ARD channels are going to start broadcasting
the standard AC3 component descriptor some time next week, I'm
publishing the attached patch that implements this in VDR 1.7.0.
From what I have been told, Premiere was the first provider that
actually broadcasted AC3 audio, and they chose not to use the
standard stream content value of '4' ("AC-3 audio"), but instead
used stream content value '2' with component type '5' ("MPEG-1 Layer
2 audio, surround sound"). And since they "certify" all their receivers,
this wrong decision was quickly adopted by other broadcasters, and
became a "pseudo standard".
Note that this patch is not necessary to receive AC-3 audio on the
ARD channels. They will still be broadcasting the old descriptors
in parallel with the new ones for about a year, so existing VDRs will
work just fine. This is just to let people who like to test this
actually do so.
The channel
MEHRKANALTEST;ARD:12421:hC34M2O0S0:S19.2E:27500:0:2001=deu;2002=deu:0:0:28397:1:1201:0
already broadcasts the new AC3 descriptor and can be used for testing
(no video, just audio test tones).
Klaus
Comments
On Sun, May 11, 2008 at 12:30:27PM +0200, Klaus Schmidinger wrote:
> However, since the German ARD channels are going to start broadcasting
> the standard AC3 component descriptor some time next week, I'm
> publishing the attached patch that implements this in VDR 1.7.0.
>
> From what I have been told, Premiere was the first provider that
> actually broadcasted AC3 audio, and they chose not to use the
> standard stream content value of '4' ("AC-3 audio"), but instead
> used stream content value '2' with component type '5' ("MPEG-1 Layer
> 2 audio, surround sound"). And since they "certify" all their receivers,
> this wrong decision was quickly adopted by other broadcasters, and
> became a "pseudo standard".
>
> Note that this patch is not necessary to receive AC-3 audio on the
> ARD channels. They will still be broadcasting the old descriptors
> in parallel with the new ones for about a year, so existing VDRs will
> work just fine. This is just to let people who like to test this
> actually do so.
>
> The channel
>
> MEHRKANALTEST;ARD:12421:hC34M2O0S0:S19.2E:27500:0:2001=deu;2002=deu:0:0:28397:1:1201:0
>
> already broadcasts the new AC3 descriptor and can be used for testing
> (no video, just audio test tones).
Hello,
AC3 was working fine for me with xine and my DD receiver BEFORE this
patch, I don't get AC3 with it now...
On Mon, May 12, 2008 at 04:01:33PM +0200, Gregoire Favre wrote:
>
> AC3 was working fine for me with xine and my DD receiver BEFORE this
> patch, I don't get AC3 with it now...
OoO I am awfully sorry : AC3 still works, it's only my pulseaudio
settings that were wrong, sorry for the missreport here :-(
The sound on :
MEHRKANALTEST;ARD:12422:hC34M2O0S0:S19.2E:27500:0:2001=deu;2002=deu:0:0:28397:1:1201:0
isn't that interesting sofar... let's hope some more is coming :-)
On Sun, May 11, 2008 at 12:30:27PM +0200, Klaus Schmidinger wrote:
> I am currently working on making the switch from PES to TS
> as the VDR recording format, that's why there are currently
> no new versions of VDR.
I'll be really interested in a vdr version using TS, any schedule on
when we could expect it ?
Thank you very much,
On 07/22/08 23:32, Gregoire Favre wrote:
> On Sun, May 11, 2008 at 12:30:27PM +0200, Klaus Schmidinger wrote:
>
>> I am currently working on making the switch from PES to TS
>> as the VDR recording format, that's why there are currently
>> no new versions of VDR.
>
> I'll be really interested in a vdr version using TS, any schedule on
> when we could expect it ?
Well, much to my regret I have had next to no time free to spend
on VDR in the past few months. There is still a new open case
sitting on my desk, awaiting to start running with DVB-S2 cards
and an eHD output device, and software-wise I'm almost finished
implementing TS for Transfer Mode. I hope it won't be long before
I'll have more time for this.
Klaus
On 23 Jul 2008, at 18:12, Klaus Schmidinger wrote:
> eHD output device
May I ask which device this is? A Reel Extension HD PCI card?
On 07/23/08 10:34, Torgeir Veimo wrote:
> On 23 Jul 2008, at 18:12, Klaus Schmidinger wrote:
>
>> eHD output device
>
>
> May I ask which device this is? A Reel Extension HD PCI card?
Yes - but I haven't come to the point where I could actually use
it, yet.
Klaus
===================================================================
RCS file: ./RCS/eit.c
retrieving revision 2.1
@@ -219,7 +219,7 @@
SI::ComponentDescriptor *cd = (SI::ComponentDescriptor *)d;
uchar Stream = cd->getStreamContent();
uchar Type = cd->getComponentType();
- if (1 <= Stream && Stream <= 3 && Type != 0) { // 1=video, 2=audio, 3=subtitles
+ if (1 <= Stream && Stream <= 4 && Type != 0) { // 1=video, 2=audio, 3=subtitles, 4=AC3
if (!Components)
Components = new cComponents;
char buffer[Utf8BufSize(256)];
===================================================================
RCS file: ./RCS/epg.c
retrieving revision 2.0
@@ -88,8 +88,10 @@
tComponent *cComponents::GetComponent(int Index, uchar Stream, uchar Type)
{
for (int i = 0; i < numComponents; i++) {
- // In case of an audio stream the 'type' check actually just distinguishes between "normal" and "Dolby Digital":
- if (components[i].stream == Stream && (Stream != 2 || (components[i].type < 5) == (Type < 5))) {
+ if (components[i].stream == Stream && (
+ Type == 0 || // don't care about the actual Type
+ Stream == 2 && (components[i].type < 5) == (Type < 5) // fallback "Dolby" component according to the "Premiere pseudo standard"
+ )) {
if (!Index--)
return &components[i];
}
===================================================================
RCS file: ./RCS/menu.c
retrieving revision 2.1
@@ -3147,6 +3147,8 @@
break;
case 3: cDevice::PrimaryDevice()->SetAvailableTrack(ttSubtitle, indexSubtitle++, 0, LiveChannel ? NULL : p->language, p->description);
break;
+ case 4: cDevice::PrimaryDevice()->SetAvailableTrack(ttDolby, indexDolby++, 0, LiveChannel ? NULL : p->language, p->description);
+ break;
}
}
}
===================================================================
RCS file: ./RCS/recording.c
retrieving revision 2.0
@@ -297,7 +297,9 @@
for (int i = 0; i < MAXDPIDS; i++) {
const char *s = Channel->Dlang(i);
if (*s) {
- tComponent *Component = Components->GetComponent(i, 2, 5);
+ tComponent *Component = Components->GetComponent(i, 4, 0); // AC3 component according to the DVB standard
+ if (!Component)
+ Component = Components->GetComponent(i, 2, 5); // fallback "Dolby" component according to the "Premiere pseudo standard"
if (!Component)
Components->SetComponent(Components->NumComponents(), 2, 5, s, NULL);
else if (strlen(s) > strlen(Component->language))
===================================================================
RCS file: ./RCS/vdr.5
retrieving revision 2.1
@@ -652,7 +652,7 @@
<title> @is the title of the event
<short text> @is the short text of the event (typically the name of the episode etc.)
<description> @is the description of the event (any '|' characters will be interpreted as newlines)
-<stream> @is the stream content (1 = video, 2 = audio, 3 = subtitles)
+<stream> @is the stream content (1 = video, 2 = audio, 3 = subtitles, 4 = AC3)
<type> @is the stream type according to ETSI EN 300 468
<language> @is the three letter language code (optionally two codes, separated by '+')
<descr> @is the description of this stream component