Hi,
I located a small bug which has been introduced in 1.7.18 (at least I think so). Reading the Changes file I could not determine which change caused it, but the problem is the following.
In pat.c: if the PMT of a service has a stream of stream-type 128 (0x80) the vpid is overridden with the PID signalled in the Elementary-PID-field of this stream. This happens to be the case here in France for some of the DVB- T services. It breaks 2 channels (France 2 and France 5) when channel- updates is at least configured to "update PIDs".
The code which is doing that is described as "STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)" which before was only applied when the stream had a certain descriptor and there a certain type.
The attached patch resets the code to do exactly that for STREAMTYPE 0x80 - though can't check whether the digiCipher-stuff is still working.
Please consider applying soon.
Thanks, -- Patrick
On 08.04.2012 18:38, Patrick Boettcher wrote:
Hi,
I located a small bug which has been introduced in 1.7.18 (at least I think so). Reading the Changes file I could not determine which change caused it, but the problem is the following.
In pat.c: if the PMT of a service has a stream of stream-type 128 (0x80) the vpid is overridden with the PID signalled in the Elementary-PID-field of this stream. This happens to be the case here in France for some of the DVB- T services. It breaks 2 channels (France 2 and France 5) when channel- updates is at least configured to "update PIDs".
The code which is doing that is described as "STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)" which before was only applied when the stream had a certain descriptor and there a certain type.
The attached patch resets the code to do exactly that for STREAMTYPE 0x80 - though can't check whether the digiCipher-stuff is still working.
+ // http://www.smpte-ra.org/mpegreg/mpegreg.html + ... + case 0x44434949: // STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)
There is no entry for 44-43-49-49 on the given page.
Klaus
On 9 April 2012 10:40, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
- // http://www.smpte-ra.org/mpegreg/mpegreg.html
- ...
- case 0x44434949: // STREAMTYPE_USER_PRIVATE -
DigiCipher II VIDEO (ANSI/SCTE 57)
There is no entry for 44-43-49-49 on the given page.
Klaus
fwiw, Patrick's patch simply re-instates the case statement that was removed in VDR 1.7.18, although with a slightly different comment against it
see pat.c diff at http://git.gekrumbel.de/vdr.git?p=vdr.git;a=commitdiff;h=f3d9ba8bfd6cd51779a...
I'm guessing this was removed as part of Rolf's patch to add DigiCipher support?
On Monday 09 April 2012 13:39:36 Dominic Evans wrote:
On 9 April 2012 10:40, Klaus Schmidinger Klaus.Schmidinger@tvdr.de
wrote:
//http://www.smpte-ra.org/mpegreg/mpegreg.html + ...
case 0x44434949: // STREAMTYPE_USER_PRIVATE
- DigiCipher II VIDEO (ANSI/SCTE 57)
There is no entry for 44-43-49-49 on the given page.
It wasn't me who added this stream-type check, I just re-applied the checks how they were done before.
see pat.c diff at http://git.gekrumbel.de/vdr.git?p=vdr.git;a=commitdiff;h=f3d9ba8bfd6cd517 79aa1d2923903949fbb92f3c
I used exactly this repository to find out that the regression was introduced in 1.7.18.
I'm guessing this was removed as part of Rolf's patch to add DigiCipher support?
Rolf contacted me off-list and confirmed your assumption.
I sent the PMT (attached here as well) of the channel to him to see whether he has an idea how it can be avoided.
In general I think just brutally replace the VPID with the PID signalled in the stream which is "user-defined" can't be the right way.
-- Patrick http://www.kernellabs.com/
On 09.04.2012 17:49, Patrick Boettcher wrote:
On Monday 09 April 2012 13:39:36 Dominic Evans wrote:
On 9 April 2012 10:40, Klaus SchmidingerKlaus.Schmidinger@tvdr.de
wrote:
//http://www.smpte-ra.org/mpegreg/mpegreg.html + ...
case 0x44434949: // STREAMTYPE_USER_PRIVATE
- DigiCipher II VIDEO (ANSI/SCTE 57)
There is no entry for 44-43-49-49 on the given page.
It wasn't me who added this stream-type check, I just re-applied the checks how they were done before.
No big deal, I was just wondering.
I have adopted your patch in the attached form. Maybe you (and/or Rolf) would like to verify it.
Klaus
On Monday 09 April 2012 17:57:20 Klaus Schmidinger wrote:
On 09.04.2012 17:49, Patrick Boettcher wrote:
On Monday 09 April 2012 13:39:36 Dominic Evans wrote:
On 9 April 2012 10:40, Klaus SchmidingerKlaus.Schmidinger@tvdr.de
wrote:
//http://www.smpte-ra.org/mpegreg/mpegreg.html +
...
case 0x44434949: //STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)
There is no entry for 44-43-49-49 on the given page.
It wasn't me who added this stream-type check, I just re-applied the checks how they were done before.
No big deal, I was just wondering.
I have adopted your patch in the attached form. Maybe you (and/or Rolf) would like to verify it.
The patch looks good to me.
In the meantime Rolf contacted me saying that it be better to move this code to a plugin which digicipher users could use if they want (at least that's what I understood).
I think he will contact you. For the time being your patch should fix it.
Thanks.
-- Patrick http://www.kernellabs.com/
Hi
A plugin why not but in our case, DVB-T in France, those channels are FTA
The real question should be why broadcaster include this ? good question !!
The patch is reported as working and fixing PPID wrong value that's the most important
Thanks for this patch
@+
Le lundi 09 avril 2012 18:23:58, Patrick Boettcher a écrit :
On Monday 09 April 2012 17:57:20 Klaus Schmidinger wrote:
On 09.04.2012 17:49, Patrick Boettcher wrote:
On Monday 09 April 2012 13:39:36 Dominic Evans wrote:
On 9 April 2012 10:40, Klaus SchmidingerKlaus.Schmidinger@tvdr.de
wrote:
//http://www.smpte-ra.org/mpegreg/mpegreg.html +
...
case 0x44434949: //STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)
There is no entry for 44-43-49-49 on the given page.
It wasn't me who added this stream-type check, I just re-applied the checks how they were done before.
No big deal, I was just wondering.
I have adopted your patch in the attached form. Maybe you (and/or Rolf) would like to verify it.
The patch looks good to me.
In the meantime Rolf contacted me saying that it be better to move this code to a plugin which digicipher users could use if they want (at least that's what I understood).
I think he will contact you. For the time being your patch should fix it.
Thanks.
-- Patrick http://www.kernellabs.com/
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 09.04.2012 20:05, Dominique wrote:
Hi
A plugin why not but in our case, DVB-T in France, those channels are FTA
The real question should be why broadcaster include this ? good question !!
The patch is reported as working and fixing PPID wrong value that's the most important
Rolf Ahrenberg has informed me that this patch breaks things for North American streams, so I'm going to revoke it again.
I wouldn't want to introduce a plugin interface for this, so unless there is a way to tell these different versions apart from the data stream, we'll need to introduce some way of making this selectable by the user. Of course, a way of detecting them automatically would be preferable.
Klaus
Le lundi 09 avril 2012 18:23:58, Patrick Boettcher a écrit :
On Monday 09 April 2012 17:57:20 Klaus Schmidinger wrote:
On 09.04.2012 17:49, Patrick Boettcher wrote:
On Monday 09 April 2012 13:39:36 Dominic Evans wrote:
On 9 April 2012 10:40, Klaus SchmidingerKlaus.Schmidinger@tvdr.de
wrote:
//http://www.smpte-ra.org/mpegreg/mpegreg.html +
...
case 0x44434949: //STREAMTYPE_USER_PRIVATE - DigiCipher II VIDEO (ANSI/SCTE 57)
There is no entry for 44-43-49-49 on the given page.
It wasn't me who added this stream-type check, I just re-applied the checks how they were done before.
No big deal, I was just wondering.
I have adopted your patch in the attached form. Maybe you (and/or Rolf) would like to verify it.
The patch looks good to me.
In the meantime Rolf contacted me saying that it be better to move this code to a plugin which digicipher users could use if they want (at least that's what I understood).
I think he will contact you. For the time being your patch should fix it.
Thanks.
-- Patrick
-
Dominic Evans -
Dominique -
Klaus Schmidinger -
Patrick Boettcher