PMT in multiple TS packet bug

  Hi Klaus,

I have noticed a PMT parsing issue with VDR version 1.7.x. The bug is still 
present in version 1.7.3 but the behaviour is worst because it segfaults.

First I found out that 2 lines where added in the ParsePmt method.

     Data += Data[0] + 1; // this is the first packet

     Length -= Data[0] + 1;

At the moment I don't know exactly what is the meaning of this 2 operations.
The second line can result in a negative Length which is the reason of the 
segfault. 
Could you kindly explain the offset drift? In a single section PMT (99.9% of 
the time) Data[0] is always equal to 0 and we skip the first byte. Length is 
reduced by 1. I a multiple section stream Data[0] can be above 188. Trying to 
skip more than a section is not possible in the actual context.

I have done a quick and dirty hack to prevent the segfault:



the second step will be to have the parsing of multiple section allowed. At 
the moment when the data size exceed the section size (max 4096), PMT cannot 
be parsed.


[2222] ERROR: can't parse PMT
[2222] ERROR: can't parse PMT
[2222] ERROR: can't parse PMT
[2222] ERROR: can't parse PMT
[2222] ERROR: can't parse PMT
[2222] ERROR: PMT section length too big (4176 byte)!
[2222] ERROR: can't parse PMT


Regards,

Alex
  

Hi,

On Mon, 19 Jan 2009 10:44:18 +0100, Alexw wrote
> I have noticed a PMT parsing issue with VDR version 1.7.x. The bug 
> is still present in version 1.7.3 but the behaviour is worst because 
> it segfaults.
> 
> First I found out that 2 lines where added in the ParsePmt method.
> 
>      Data += Data[0] + 1; // this is the first packet
> 
>      Length -= Data[0] + 1;
> 
> At the moment I don't know exactly what is the meaning of this 2 operations.

These lines are for handling the SI pointer field. Data[0] is the pointer
field, which contains the byte offset to the actual data (usually 0). "+ 1"
for the pointer field itself. 

The order of the two statements need to be reversed. First fix the length,
then the data pointer:

     Length -= Data[0] + 1;
     Data += Data[0] + 1;

Cheers,
Frank
  

I have already tested the inversion. Reducing the length and after moving to 
the new offset. This change does not solve the issue. The Length variable can 
still decrease to a negative value. 

What happen when the byte offset is greater than 188?
  

On 19.01.2009 11:06, Frank Schmirler wrote:
> Hi,
> 
> On Mon, 19 Jan 2009 10:44:18 +0100, Alexw wrote
>> I have noticed a PMT parsing issue with VDR version 1.7.x. The bug 
>> is still present in version 1.7.3 but the behaviour is worst because 
>> it segfaults.
>>
>> First I found out that 2 lines where added in the ParsePmt method.
>>
>>      Data += Data[0] + 1; // this is the first packet
>>
>>      Length -= Data[0] + 1;
>>
>> At the moment I don't know exactly what is the meaning of this 2 operations.
> 
> These lines are for handling the SI pointer field. Data[0] is the pointer
> field, which contains the byte offset to the actual data (usually 0). "+ 1"
> for the pointer field itself. 
> 
> The order of the two statements need to be reversed. First fix the length,
> then the data pointer:
> 
>      Length -= Data[0] + 1;
>      Data += Data[0] + 1;

Mea culpa!
It was correct in Frank's original patch, but for some
silly reason I swapped these two lines when adopting the patch.
Sorry about that...

Will fix it in 1.7.4.

Klaus
  

On Mon, 19 Jan 2009 11:20:45 +0100, Alexw wrote
> I have already tested the inversion. Reducing the length and after 
> moving to the new offset. This change does not solve the issue. The 
> Length variable can still decrease to a negative value.
> 
> What happen when the byte offset is greater than 188?

Then the packet was broken and shouldn't have been processed at all. By
definition the pointer field is the number of bytes to skip in *this* TS
packet. As the pointer field is not covered by a CRC check, it could be wrong.
So you're right, it should be checked. Note that this does not only affect
cRemux::ParsePmt() but also cRemux::ParsePat().

Regards,
Frank
  

Yes Frank you are right. The problem is coming from bad CRC in the PMT (and 
the same apply to bad PAT). If Pmt.CheckCRCAndParse() fails, bad PMT data 
should be skipped.

@Klaus: will you look at this enhancement before rolling out 1.7.4?
  

On Mon, 19 Jan 2009 13:32:07 +0100, Alexw wrote
> Yes Frank you are right. The problem is coming from bad CRC in the 
> PMT (and the same apply to bad PAT). If Pmt.CheckCRCAndParse() fails,
>  bad PMT data should be skipped.

Bad CRC is caught by CheckCRCAndParse(). What I had in mind is a wrong value
in the pointer field itself (e.g. due to bad weather conditions). In
ParsePat() something like

if (Data[0] + 1 >= Length) return;

should be sufficient. The same check is fine for ParsePmt(), but I'd
additionally suggest to pass the TS PUSI field as third parameter. Otherwise
it would not be possible to distinguish the first fragment from fragments
following a broken one.

if (PUSI)
  // this is the first packet
  if (Data[0] + 1 >= Length) return;
  ...
else if (pmtSize == 0)
  // fragment of broken packet - ignore
  return;
else
  // this is a following packet, so we add it to the pmt storage
  ...

Cheers,
Frank
  

Hi,

I did check the TS stream with dvbsnoop and it is not containing corrupted TS 
packets.

Apparently VDR is able to parse the PMT the first time the data buffer is 
used. Then, it seems to loose the sync inside the payload.

I have attached a raw TS capture (~10M) containing the PMT pid 132 which is 
revealing the problem.

http://alexw.org.lu/upload/pmt.pid.132.ts

Regards,

Alex
  

> I did check the TS stream with dvbsnoop and it is not containing corrupted TS
> packets.
>
> Apparently VDR is able to parse the PMT the first time the data buffer is
> used. Then, it seems to loose the sync inside the payload.
>
> I have attached a raw TS capture (~10M) containing the PMT pid 132 which is
> revealing the problem.
>
> http://alexw.org.lu/upload/pmt.pid.132.ts

Could this patch help with vdr-1.7.3?

http://article.gmane.org/gmane.linux.vdr/39097

Mika
  

Hi Mika,

I have already applied the mentioned patch ;-) But unfortunately it does not 
solve the issue.

Cheers,

Alex
  

On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> I have attached a raw TS capture (~10M) containing the PMT pid 132 
> which is revealing the problem.

Hum - PID 132 is a french dolby track, not a PMT PID...

Cheers,
Frank
  

On 20.01.2009 16:01, Frank Schmirler wrote:
> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
>> I have attached a raw TS capture (~10M) containing the PMT pid 132 
>> which is revealing the problem.
> 
> Hum - PID 132 is a french dolby track, not a PMT PID...

VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132.
This was taken from some patch that implemented PAT/PMT handling
(don't remember which one it was, maybe it was even the code from
reel multimedia - not sure if I've missed mentioning that in the
CONTRIBUTORS file).

Anyway, I was already wondering if simply using some fixed PMT
pid was such a good idea. What if some other stream uses exactly
that pid? Apparently this is the case in this example.

So I guess it will be necessary to first collect all pids and then
check whether the default pseudo PMT pid is still free, and if
not, incresase it until a free one is found...

Klaus
  

On Dienstag, 20. Januar 2009, Klaus Schmidinger wrote:
>
> VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132.
> This was taken from some patch that implemented PAT/PMT handling
> (don't remember which one it was, maybe it was even the code from
> reel multimedia - not sure if I've missed mentioning that in the
> CONTRIBUTORS file).
>
> Anyway, I was already wondering if simply using some fixed PMT
> pid was such a good idea. What if some other stream uses exactly
> that pid? Apparently this is the case in this example.
>
> So I guess it will be necessary to first collect all pids and then
> check whether the default pseudo PMT pid is still free, and if
> not, incresase it until a free one is found...
>

How about just using the original PMT pid?

Matthias
  

oops, it's a mistake. I am making reference to PMT pid 100 (sid 1537)

Thanks for having spotted that.

Cheers,

Alex
  

On Tue, Jan 20, 2009 at 04:01:17PM +0100, Frank Schmirler wrote:
> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> > I have attached a raw TS capture (~10M) containing the PMT pid 132 
> > which is revealing the problem.
> 
> Hum - PID 132 is a french dolby track, not a PMT PID...
> 
> Cheers,
> Frank
> 
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Frank, good shot. VDR is trying to parse PID 132 as if it was a PMT !!!

I have added a log message inside device.c and I have found that patPmtParser.PmtPid() returns pid 132 as PMT.
The error can be localized in the patPmtParser.PmtPid function. It is a good progress.


PAT: TSid = 32776, c/n = 1, v = 0, s = 0, ls = 0
     isNITPid = 0
     service id = 132, pid = 132
[5832] PMT PID = 132
PMT: sid = 132, c/n = 1, v = 0, s = 0, ls = 0
     pcr = 120
     stream type = 02, pid = 120
     stream type = 04, pid = 130 'fra'
     stream type = 04, pid = 131 'eng'
     stream type = 04, pid = 133 'deu'
     stream type = 06, pid = 132 AC3 'fra'
[5846] PMT PID = 132
[5846] PMT PID = 132
[5846] PMT PID = 132
[5846] ERROR: can't parse PMT
  

On Tue, Jan 20, 2009 at 04:11:17PM +0100, Klaus Schmidinger wrote:
> On 20.01.2009 16:01, Frank Schmirler wrote:
> > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> >> I have attached a raw TS capture (~10M) containing the PMT pid 132 
> >> which is revealing the problem.
> > 
> > Hum - PID 132 is a french dolby track, not a PMT PID...
> 
> VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132.
> This was taken from some patch that implemented PAT/PMT handling
> (don't remember which one it was, maybe it was even the code from
> reel multimedia - not sure if I've missed mentioning that in the
> CONTRIBUTORS file).
> 
> Anyway, I was already wondering if simply using some fixed PMT
> pid was such a good idea. What if some other stream uses exactly
> that pid? Apparently this is the case in this example.

I confirm, we ran into this special situation.

> 
> So I guess it will be necessary to first collect all pids and then
> check whether the default pseudo PMT pid is still free, and if
> not, incresase it until a free one is found...
> 

Too difficult because a low repetition rate PID can be ommitted by the collector. (DTD pid for example)

Why not taking the real PMT pid to create the pseudo PID for the PAT? At the moment I do not really understand why this mechanism is needed in transfer mode.

Alex

> Klaus
> 
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

Klaus Schmidinger wrote:
> On 20.01.2009 16:01, Frank Schmirler wrote:
> > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> >> I have attached a raw TS capture (~10M) containing the PMT pid 132 
> >> which is revealing the problem.
> > 
> > Hum - PID 132 is a french dolby track, not a PMT PID...
> 
> VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132.
> This was taken from some patch that implemented PAT/PMT handling
> (don't remember which one it was, maybe it was even the code from
> reel multimedia - not sure if I've missed mentioning that in the
> CONTRIBUTORS file).
> 
> Anyway, I was already wondering if simply using some fixed PMT
> pid was such a good idea. What if some other stream uses exactly
> that pid? Apparently this is the case in this example.
> 
> So I guess it will be necessary to first collect all pids and then
> check whether the default pseudo PMT pid is still free, and if
> not, incresase it until a free one is found...

Hm - why don't you use the PID of the original PMT?

CU
Oliver
  

On 20.01.2009 22:18, Oliver Endriss wrote:
> Klaus Schmidinger wrote:
>> On 20.01.2009 16:01, Frank Schmirler wrote:
>>> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
>>>> I have attached a raw TS capture (~10M) containing the PMT pid 132 
>>>> which is revealing the problem.
>>> Hum - PID 132 is a french dolby track, not a PMT PID...
>> VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132.
>> This was taken from some patch that implemented PAT/PMT handling
>> (don't remember which one it was, maybe it was even the code from
>> reel multimedia - not sure if I've missed mentioning that in the
>> CONTRIBUTORS file).
>>
>> Anyway, I was already wondering if simply using some fixed PMT
>> pid was such a good idea. What if some other stream uses exactly
>> that pid? Apparently this is the case in this example.
>>
>> So I guess it will be necessary to first collect all pids and then
>> check whether the default pseudo PMT pid is still free, and if
>> not, incresase it until a free one is found...
> 
> Hm - why don't you use the PID of the original PMT?

Because I don't have it ;-)
It would be yet another parameter that needs to be stored in the
channels.conf.

I'll do it the way I mentioned, just need to give the cPatPmtGenerator
the channel in the constructor so that it can choose a PMT pid that
is different than any of the channel's other pids.

Klaus
  

Hi. I've just made the switch to S2API and vdr-1.7.4 and it seems to work
quite well both with xineliboutput (with vdpau) and streamdev now. The thing
I'm missing is teletext subtitles and I don't know how hard it would be to
update it for ts. Has anyone started on this? What countries other than
Sweden and Finland use teletext subtitles frequently? I understand that it
is not one of your (Klaus) top priorities, but do you have access to any
channels that use it? Otherwise it's probably even lower on the priorities
list.
One feature request for VDR: a setup option to record all pids, including
all audio and teletext pids. That way I guess it would be easier to develop
a plugin for it (and I'd be happy to send you some recordings).
/Magnus H
  

On 26.02.2009 12:08, Magnus Hörlin wrote:
> Hi. I've just made the switch to S2API and vdr-1.7.4 and it seems to work
> quite well both with xineliboutput (with vdpau) and streamdev now. The thing
> I'm missing is teletext subtitles and I don't know how hard it would be to
> update it for ts. Has anyone started on this? What countries other than
> Sweden and Finland use teletext subtitles frequently? I understand that it
> is not one of your (Klaus) top priorities, but do you have access to any
> channels that use it? Otherwise it's probably even lower on the priorities
> list.

I believe the German ZDF channel broadcasts both ttxt and DVB subtitles.

> One feature request for VDR: a setup option to record all pids, including
> all audio and teletext pids. That way I guess it would be easier to develop
> a plugin for it (and I'd be happy to send you some recordings).

It already records all audio pids.
I wouldn't want to record the ttxt pid just because of a few bytes for
subtitles. Here's a copy of a message I just sent to Rolf Ahrenberg
privately, after he sent me a suggested patch to record the ttxt pid:

----------------------------------------------------------------------
...teletext subtitles are a thing from the past, the normal way
of broadcasting subtitles should be DVB subtitles. I hardly think a
DVD player would be able to handle teletext subtitles (or am I wrong here?).

I would prefer a solution where the teletext subtitles are converted into
DVB subtitles during recording (and also during live viewing). Then the
rest of VDR would only have to handle one single subtitle format.

I suggest you first write a class that accepts a teletext TS data
stream and outputs a DVB subtitle TS stream. Then we can see how
this can be inserted into the recording chain and during live viewing.
Something like

class cTtxtToDvbSubtitles {
...
public:
  cTtxtToDvbSubtitles(int Page); // the teletext page containing the subtitles
  void PutTtxtTs(uchar *Data, int Length); // put a single TS packet of ttxt data
                                           // into the converter
  uchar *GetDvbTs(int &Length); // get one or more TS packets containing a complete
                                // DVB subtitle page
  ...
  };

What we also need is a way of detecting whether there are any ttxt subtitles,
and on which page they are broadcast (haven't looked into the DVB standard
about this yet, but I believe every broadcaster uses a different page).

Once we have these facilities, this could well go into the core VDR.
----------------------------------------------------------------------


Klaus
  

On 28.02.2009 11:42, Klaus Schmidinger wrote:
> What we also need is a way of detecting whether there are any ttxt subtitles,
> and on which page they are broadcast (haven't looked into the DVB standard
> about this yet, but I believe every broadcaster uses a different page).

The teletext standard defines a teletext subtitle flag that any subtitle 
page should have set. Specifically, its the C6 flag, placed at byte 11 
bit 8 of line 0 of the teletext page. (see cTxtReceiver::DecodeTXT of 
OSDTeletext on how to get that flag.)

However, I don't know how consequently this flag is used. The C5 
(Newsflash) flag also sets a transparent background, and could be used 
alternatively. Other transparent pages could also falsely set the C6 flag.
It also may be a good idea to interpret different teletext pages as 
different subtitles, in case a channel has more than one subtitle page.


Cheers,

Udo
  

En/na Klaus Schmidinger ha escrit:


> ...teletext subtitles are a thing from the past, the normal way
> of broadcasting subtitles should be DVB subtitles. I hardly think a
> DVD player would be able to handle teletext subtitles (or am I wrong here?).

While I agree that dvb subtitles are usually better than teletext 
subtitles, there are cases when it isn't so.
For example, itv3 (shoot me, but I like Poirot) broadcasts both teletext 
and dvb subtitles, but the dvb subtitles are ~6 seconds early, so 
they're unusable.
Btw, a 20€ dvb-t set-top box handles teletext subtitles just fine.

Bye
  

On 28.02.2009 15:54, Luca Olivetti wrote:
> En/na Klaus Schmidinger ha escrit:
> 
> 
>> ...teletext subtitles are a thing from the past, the normal way
>> of broadcasting subtitles should be DVB subtitles. I hardly think a
>> DVD player would be able to handle teletext subtitles (or am I wrong here?).
> 
> While I agree that dvb subtitles are usually better than teletext 
> subtitles, there are cases when it isn't so.
> For example, itv3 (shoot me, but I like Poirot) broadcasts both teletext 
> and dvb subtitles, but the dvb subtitles are ~6 seconds early, so 
> they're unusable.

Have you ever inquired why they don't fix this?

Klaus
  

En/na Klaus Schmidinger ha escrit:
> On 28.02.2009 15:54, Luca Olivetti wrote:
>> En/na Klaus Schmidinger ha escrit:
>>
>>
>>> ...teletext subtitles are a thing from the past, the normal way
>>> of broadcasting subtitles should be DVB subtitles. I hardly think a
>>> DVD player would be able to handle teletext subtitles (or am I wrong here?).
>> While I agree that dvb subtitles are usually better than teletext 
>> subtitles, there are cases when it isn't so.
>> For example, itv3 (shoot me, but I like Poirot) broadcasts both teletext 
>> and dvb subtitles, but the dvb subtitles are ~6 seconds early, so 
>> they're unusable.
> 
> Have you ever inquired why they don't fix this?

No, I'm using teletex subtitles instead ;-)
I'm not supposed to be receiving uk channels (in theory the beam is 
focused on the uk), so I cannot really complain.
Besides, I'm not knowledgeable enough to be sure it's their problem or 
vdr problem (after all, if it didn't work with the freeview set-top 
boxes, they'd surely fix it, wouldn't they?)
OTOH I never had problems with dvb subtitles on the bbc channels (other 
than vdr not recognizing they're there in recordings, while they 
automatically show in live view).

Bye
  

On 28.02.2009 16:38, Luca Olivetti wrote:
> En/na Klaus Schmidinger ha escrit:
>> On 28.02.2009 15:54, Luca Olivetti wrote:
>>> En/na Klaus Schmidinger ha escrit:
>>>
>>>
>>>> ...teletext subtitles are a thing from the past, the normal way
>>>> of broadcasting subtitles should be DVB subtitles. I hardly think a
>>>> DVD player would be able to handle teletext subtitles (or am I wrong here?).
>>> While I agree that dvb subtitles are usually better than teletext 
>>> subtitles, there are cases when it isn't so.
>>> For example, itv3 (shoot me, but I like Poirot) broadcasts both teletext 
>>> and dvb subtitles, but the dvb subtitles are ~6 seconds early, so 
>>> they're unusable.
>> Have you ever inquired why they don't fix this?
> 
> No, I'm using teletex subtitles instead ;-)
> I'm not supposed to be receiving uk channels (in theory the beam is 
> focused on the uk), so I cannot really complain.
> Besides, I'm not knowledgeable enough to be sure it's their problem or 
> vdr problem (after all, if it didn't work with the freeview set-top 
> boxes, they'd surely fix it, wouldn't they?)
> OTOH I never had problems with dvb subtitles on the bbc channels (other 
> than vdr not recognizing they're there in recordings, while they 
> automatically show in live view).

Please send me the channels.conf line of itv3 - I'd like to take a look
at this myself.

Klaus
  

En/na Klaus Schmidinger ha escrit:

> Please send me the channels.conf line of itv3 - I'd like to take a look
> at this myself.

ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0

Bye
  

On 28.02.2009 18:35, Luca Olivetti wrote:
> En/na Klaus Schmidinger ha escrit:
> 
>> Please send me the channels.conf line of itv3 - I'd like to take a look
>> at this myself.
> 
> ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0

Just took a look, and they are perfectly in sync.

Klaus
  

En/na Klaus Schmidinger ha escrit:
> On 28.02.2009 18:35, Luca Olivetti wrote:
>> En/na Klaus Schmidinger ha escrit:
>>
>>> Please send me the channels.conf line of itv3 - I'd like to take a look
>>> at this myself.
>> ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
> 
> Just took a look, and they are perfectly in sync.

Strange, I see them a little bit early right now (not much) but it's 
worse with recordings.
Maybe it's just Poirot, but I swear I have to use teletext subtitles 
with those recordings.


Bye
  

En/na Luca Olivetti ha escrit:
> En/na Klaus Schmidinger ha escrit:
>> On 28.02.2009 18:35, Luca Olivetti wrote:
>>> En/na Klaus Schmidinger ha escrit:
>>>
>>>> Please send me the channels.conf line of itv3 - I'd like to take a look
>>>> at this myself.
>>> ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
>> Just took a look, and they are perfectly in sync.
> 
> Strange, I see them a little bit early right now (not much) but it's 
> worse with recordings.
> Maybe it's just Poirot, but I swear I have to use teletext subtitles 
> with those recordings.

I uploaded a short (14M bytes) clip with the subtitles out of sync.
http://personales.ya.com/ventoso/poirot.tar

Bye
  

On Sat, 28 Feb 2009 19:29:07 +0100
Luca Olivetti <luca@ventoso.org> wrote:

[Subtitles out of sync]

> En/na Klaus Schmidinger ha escrit:
> > On 28.02.2009 18:35, Luca Olivetti wrote:
> >> En/na Klaus Schmidinger ha escrit:
> >>
> >>> Please send me the channels.conf line of itv3 - I'd like to take a look
> >>> at this myself.
> >> ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
> > 
> > Just took a look, and they are perfectly in sync.
> 
> Strange, I see them a little bit early right now (not much) but it's 
> worse with recordings.
> Maybe it's just Poirot, but I swear I have to use teletext subtitles 
> with those recordings.

What sort of output device are you using? Maybe xine or whatever your
decoder is has a problem that Klaus' hardware decoder doesn't?

I've also noticed that A/V sync problems are much more likely and/or
severe with recordings than live TV. Maybe the switch to TS recording
will correct that. Additionally, it seems to me that old programmes,
especially films, are the most prone to A/V sync problems.
  

En/na Tony Houghton ha escrit:
> On Sat, 28 Feb 2009 19:29:07 +0100
> Luca Olivetti <luca@ventoso.org> wrote:
> 
> [Subtitles out of sync]
> 
>> En/na Klaus Schmidinger ha escrit:
>>> On 28.02.2009 18:35, Luca Olivetti wrote:
>>>> En/na Klaus Schmidinger ha escrit:
>>>>
>>>>> Please send me the channels.conf line of itv3 - I'd like to take a look
>>>>> at this myself.
>>>> ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
>>> Just took a look, and they are perfectly in sync.
>> Strange, I see them a little bit early right now (not much) but it's 
>> worse with recordings.
>> Maybe it's just Poirot, but I swear I have to use teletext subtitles 
>> with those recordings.
> 
> What sort of output device are you using? Maybe xine or whatever your
> decoder is has a problem that Klaus' hardware decoder doesn't?

I thought of that (I'm using both xine and a dxr3), but that's the only 
channel where I have dvb subtitles out of sync.
In fact, with networked xine, teletext subtitles are usually quite bad 
in recordings (that's the reason at the time I patched the plugin to 
delay them), while I never had problems with dvb subtitles (except for 
the above mentioned itv3).

> I've also noticed that A/V sync problems are much more likely and/or
> severe with recordings than live TV. Maybe the switch to TS recording
> will correct that. Additionally, it seems to me that old programmes,
> especially films, are the most prone to A/V sync problems.

No, I don't have any problem with A/V sync.


Bye
  

En/na Luca Olivetti ha escrit:
> En/na Klaus Schmidinger ha escrit:
>> On 28.02.2009 18:35, Luca Olivetti wrote:
>>> En/na Klaus Schmidinger ha escrit:
>>>
>>>> Please send me the channels.conf line of itv3 - I'd like to take a look
>>>> at this myself.
>>> ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
>> Just took a look, and they are perfectly in sync.
> 
> Strange, I see them a little bit early right now (not much) but it's 
> worse with recordings.
> Maybe it's just Poirot, but I swear I have to use teletext subtitles 
> with those recordings.

Definitely it's Poirot: today recording has no dvb subtitles at all 
(though they're advertised), but the teletext subtitles are there.
Guess I'll have to look Sherlock Holmes instead ;-)

Bye
  

Hi,

juste a note to say that we also have teletext subtitles in France.
I have tried vdr 1.7.4 which works perfectly except for the ttxt subs.
I have to hold my final migration to 1.7.4 until I get ttxtsubs working
again ...

Regards

2009/3/2 Luca Olivetti <luca@ventoso.org>

> En/na Luca Olivetti ha escrit:
> > En/na Klaus Schmidinger ha escrit:
> >> On 28.02.2009 18:35, Luca Olivetti wrote:
> >>> En/na Klaus Schmidinger ha escrit:
> >>>
> >>>> Please send me the channels.conf line of itv3 - I'd like to take a
> look
> >>>> at this myself.
> >>>
> ITV3;BSkyB:10906:vC56M2O0S0:S28.2E:22000:3348:3349=eng,3350=NAR:2373:0:10260:2:2054:0
> >> Just took a look, and they are perfectly in sync.
> >
> > Strange, I see them a little bit early right now (not much) but it's
> > worse with recordings.
> > Maybe it's just Poirot, but I swear I have to use teletext subtitles
> > with those recordings.
>
> Definitely it's Poirot: today recording has no dvb subtitles at all
> (though they're advertised), but the teletext subtitles are there.
> Guess I'll have to look Sherlock Holmes instead ;-)
>
> Bye
> --
> Luca
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

Hi. VDR 1.x was MPEG2-only and recorded in MPEG-PES. Now that it can do
MPEG4 AVC/AAC, and records in MPEG-TS, isn't it time to rename it 2.0 after
1.7.5?
/Magnus H
  

Magnus Hörlin schrieb:
> Hi. VDR 1.x was MPEG2-only and recorded in MPEG-PES. Now that it can do
> MPEG4 AVC/AAC, and records in MPEG-TS, isn't it time to rename it 2.0 after
> 1.7.5?
> /Magnus H
>   
Brilliant Idea. That will boost the sales numbers to the limits :)


SCNR
Peter

>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
  

ROTFL

Peter Evertz schrieb:
> Magnus Hörlin schrieb:
>> Hi. VDR 1.x was MPEG2-only and recorded in MPEG-PES. Now that it can do
>> MPEG4 AVC/AAC, and records in MPEG-TS, isn't it time to rename it 2.0 after
>> 1.7.5?
>> /Magnus H
>>   
> Brilliant Idea. That will boost the sales numbers to the limits :)
> 
> 
> SCNR
> Peter
> 
>>
>> _______________________________________________
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>>   
> 
> 
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 
>
  

On Mon, Mar 16, 2009 at 6:05 AM, Peter Evertz <leo2@pec.homeip.net> wrote:
> Magnus Hörlin schrieb:
>> Hi. VDR 1.x was MPEG2-only and recorded in MPEG-PES. Now that it can do
>> MPEG4 AVC/AAC, and records in MPEG-TS, isn't it time to rename it 2.0 after
>> 1.7.5?
>> /Magnus H
>>
> Brilliant Idea. That will boost the sales numbers to the limits :)

lol!  One of the best posts I've seen in a while! ;)