[ANNOUNCE] H.264 updates for VDR-1.5.9

  Hi,

the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
The changes to earlier releases are:

- H264::cParser has been enhanced to provide information for
  H264::cContext::GetFramesPerSec() and therefore outsourced
  into separate files.
- cVideoRepacker generates Access Unit Delimiters in case they
  are not part of the stream.

These changes should make VDR ready for the upcoming IFA fair in regard
to the broadcasts on the temporary channel EinsFestival HD.

The other attached patch vdr-1.5.9-framespersec.patch tries to replace
the macro FRAMESPERSEC by a function call GetFramesPerSec() which
analyses a recordings first video frame to determine frames per second
which are used to calculated a recordings length. The changes to earlier
releases are:

- add support for H.264 recordings by making use of the above
  mentioned H264::cParser, as frame timing stuff is quite complex.
  H.264 support can be turned off by putting a comment around the
  macro ADD_H264_SUPPORT in tools.c.

This change provides correct recording length reports for recordings
taken on EinsFestival HD as this channel broadcasts 50p, i. e. without
the patch, VDR will report recording times which are twice the actual time.

The patch in general may especially be useful for people with PAL and
NTSC recordings, as in this scenario it was never possible to find a
single setting for FRAMESPERSEC.
Although FRAMESPERSEC has been replaced on many locations, it is still
used to read/write cutting marks file, to stay compatible.

Have fun while expecting the next vdr-xine-release ;-)

Bye.
  

Reinhard Nissl wrote:
> Hi,
> 
> the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
> The changes to earlier releases are:
> 
> - H264::cParser has been enhanced to provide information for
>   H264::cContext::GetFramesPerSec() and therefore outsourced
>   into separate files.
> - cVideoRepacker generates Access Unit Delimiters in case they
>   are not part of the stream.

Should this patch make it possible to record H.264 encoded stream? I 
have applied the patch and can see in the channels menu that Canal+ HD 
Film uses H.264 codec, but I can not record the channel (nor watch it...).

-Petri
  

Hi,

Petri Helin wrote:

>> the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
>> The changes to earlier releases are:
>>
>> - H264::cParser has been enhanced to provide information for
>>   H264::cContext::GetFramesPerSec() and therefore outsourced
>>   into separate files.
>> - cVideoRepacker generates Access Unit Delimiters in case they
>>   are not part of the stream.
> 
> Should this patch make it possible to record H.264 encoded stream? I 

It should. It works for the German DVB-S2 HD channels on Astra and it
worked for LuxeTV HD on Hotbird in the past.

> have applied the patch and can see in the channels menu that Canal+ HD 
> Film uses H.264 codec, but I can not record the channel (nor watch it...).

Is this the channel you've mentioned (I've applied a DVB-S2 patch, so
the entry may differ from your's a little)?

CANAL+ FILM
HD;Harmonic:11470:vC56M2S0Z0:S13.0E:27500:10331+331:332=pol;333=ORY:551:100:15423:318:1400:0

On my system, VDR says this channel is encrypted. Do you have the
necessary means to receive this channel?

Bye.
  

On Wed, Aug 29, 2007 at 11:38:39PM +0300, Petri Helin wrote:
> Reinhard Nissl wrote:
> > Hi,
> > 
> > the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
> > The changes to earlier releases are:
> > 
> > - H264::cParser has been enhanced to provide information for
> >   H264::cContext::GetFramesPerSec() and therefore outsourced
> >   into separate files.
> > - cVideoRepacker generates Access Unit Delimiters in case they
> >   are not part of the stream.
> 
> Should this patch make it possible to record H.264 encoded stream? I 
> have applied the patch and can see in the channels menu that Canal+ HD 
> Film uses H.264 codec, but I can not record the channel (nor watch it...).
> 
> -Petri
I did apply this h264 patch and streamdev patch from: 
http://www.vdr-developer.org/mantisbt/view.php?id=382

Now the load of the server is low when tuned to Canal+ HD and I can watch the stream using vlc.
The recording at least outputs something to hard disk ;)

...hanu
  

Reinhard Nissl wrote:
> Hi,
> 
> Petri Helin wrote:
> 
>>> the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
>>> The changes to earlier releases are:
>>>
>>> - H264::cParser has been enhanced to provide information for
>>>   H264::cContext::GetFramesPerSec() and therefore outsourced
>>>   into separate files.
>>> - cVideoRepacker generates Access Unit Delimiters in case they
>>>   are not part of the stream.
>> Should this patch make it possible to record H.264 encoded stream? I 
> 
> It should. It works for the German DVB-S2 HD channels on Astra and it
> worked for LuxeTV HD on Hotbird in the past.
> 
>> have applied the patch and can see in the channels menu that Canal+ HD 
>> Film uses H.264 codec, but I can not record the channel (nor watch it...).
> 
> Is this the channel you've mentioned (I've applied a DVB-S2 patch, so
> the entry may differ from your's a little)?
> 
> CANAL+ FILM
> HD;Harmonic:11470:vC56M2S0Z0:S13.0E:27500:10331+331:332=pol;333=ORY:551:100:15423:318:1400:0
> 
> On my system, VDR says this channel is encrypted. Do you have the
> necessary means to receive this channel?
> 

The channel I mean is the same, I think, but provided by my local cable 
operator. Here is the entry in channels.conf:
Canal+ Film 
HD;Telenor:330000:C0M256:C:6900:10512+512:640=eng;641=eng:0:B00:3306:0:22:0

I have a valid subscription and this particular channel dis work when I 
tested it with the ts-recording and h264-patches available here: 
http://phivdr.dyndns.org/vdr

My subscription is ending in 24 hours, so I'd like to know if I can 
record the channel before making my mind whether to continue the 
subscription ;)

-Petri
  

Hi,

Petri Helin wrote:

> The channel I mean is the same, I think, but provided by my local cable 
> operator. Here is the entry in channels.conf:
> Canal+ Film 
> HD;Telenor:330000:C0M256:C:6900:10512+512:640=eng;641=eng:0:B00:3306:0:22:0
> 
> I have a valid subscription and this particular channel dis work when I 
> tested it with the ts-recording and h264-patches available here: 
> http://phivdr.dyndns.org/vdr

Can you provide me with a few MB of TS stream from that channel?

Something like czap and cat /dev/dvb/adapterX/dvr0 > sample.ts should do
the trick.

> My subscription is ending in 24 hours, so I'd like to know if I can 
> record the channel before making my mind whether to continue the 
> subscription ;)

Then you have to hurry now, I won't have much time tomorrow evening.

Bye.
  

Hi,

Reinhard Nissl wrote:

> Can you provide me with a few MB of TS stream from that channel?
> 
> Something like czap and cat /dev/dvb/adapterX/dvr0 > sample.ts should do
> the trick.

The TS sample you've sent me looks ok, i. e. it can be parsed by
H264::cParser.

Please locate the following location in cVideoRepacker::Repack() in file
remux.c:

  // remember start of the data
  const uchar *payload = data;
  const uchar *NalPayload = payload;

  while (todo > 0) {

and add the following line before the while:

if (h264parser) { static FILE *f = fopen("/video/sample.es.h264", "wb");
fwrite(data, 1, todo, f); fflush(f); }

The line will write the PES packet's content into file
/video/sample.es.h264 when a h264parser exists. Then please send me some
MB of the file.

Bye.
  

Hi,

Reinhard Nissl wrote:

> The line will write the PES packet's content into file
> /video/sample.es.h264 when a h264parser exists. Then please send me some
> MB of the file.

The file you've sent me doesn't contain any useful data. You can have a
look at it yourself:

od -Ax -t x1 -v sample2.es.h264 | less -S

You need to find at least the sequence 00 00 01. Otherwise it's garbage.

I'll go to bed soon, so here's a quick description how to go on:

- add this function to cRepacker
  virtual void LogTS(const uint8_t *Buf) {}
- add this function to cVideoRepacker
  virtual void LogTS(const uint8_t *Buf) { if (h264parser) { static FILE
*f = fopen("/video/sample.ts", "wb"); fwrite(Buf, 1, 188, f); fflush(f); } }
- change this area in ts_to_pes() like that:

void cTS2PES::ts_to_pes(const uint8_t *Buf) // don't need count (=188)
{
  if (!Buf)
     return;
if (repacker) repacker->LogTS(Buf);
  if (Buf[1] & TS_ERROR)

Be careful to just have a single cVideoRepacker instance write into this
file, i. e. either activate transfer mode on this channel or make a
recording on this channel but not both at the same time.

Have a look at this file with

od -Ax -t x1 -v -w188 sample.ts | less -S

and locate the sequence 00 00 01 multiple times. It should then be
possible to record this channel although it doesn't work for now, as
cVideoRepacker didn't find any startcode (00 00 01) in the
sample.es.h264 from above.

Bye.
  

Reinhard Nissl wrote:
> Hi,
> 
> Reinhard Nissl wrote:
> 
>> The line will write the PES packet's content into file
>> /video/sample.es.h264 when a h264parser exists. Then please send me some
>> MB of the file.
> 
> The file you've sent me doesn't contain any useful data. You can have a
> look at it yourself:
> 
> od -Ax -t x1 -v sample2.es.h264 | less -S
> 
> You need to find at least the sequence 00 00 01. Otherwise it's garbage.
> 
> I'll go to bed soon, so here's a quick description how to go on:
> 
> - add this function to cRepacker
>   virtual void LogTS(const uint8_t *Buf) {}
> - add this function to cVideoRepacker
>   virtual void LogTS(const uint8_t *Buf) { if (h264parser) { static FILE
> *f = fopen("/video/sample.ts", "wb"); fwrite(Buf, 1, 188, f); fflush(f); } }
> - change this area in ts_to_pes() like that:
> 
> void cTS2PES::ts_to_pes(const uint8_t *Buf) // don't need count (=188)
> {
>   if (!Buf)
>      return;
> if (repacker) repacker->LogTS(Buf);
>   if (Buf[1] & TS_ERROR)
> 
> Be careful to just have a single cVideoRepacker instance write into this
> file, i. e. either activate transfer mode on this channel or make a
> recording on this channel but not both at the same time.
> 
> Have a look at this file with
> 
> od -Ax -t x1 -v -w188 sample.ts | less -S
> 
> and locate the sequence 00 00 01 multiple times. It should then be
> possible to record this channel although it doesn't work for now, as
> cVideoRepacker didn't find any startcode (00 00 01) in the
> sample.es.h264 from above.
> 
> Bye.

I have made the changes and did some testing, but there are no "00 00 
01" series in the data at all. Some strange patterns I can see, but 
mostly just garbage. I will try again this evening when I can be sure 
that there is a program running.

Fortunately I remembered wrong the end date of my subscription, it is 
valid until the end of this month, so I have 24 hours more to test this...

-Petri
  

> Reinhard Nissl wrote:
> the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.

Hi,
I trying to compile vdr-1.5.9 with h264 patches but vdr-xine-0.7.10 plugin give 
me error:

xineDevice.c: In member function 'int PluginXine::cXineDevice::PlayCommon3(const 
uchar*, int, int64_t)':
xineDevice.c:1387: error: cannot call member function 'int 
cRemux::ScanVideoPacket(const uchar*, int, int, uchar&)' without object
xineDevice.c: In function 'bool PluginXine::getPTS(const uchar*, int, int64_t&, 
bool, bool, double&, double&, double&, double&, double*)':
xineDevice.c:2017: error: cannot call member function 'int 
cRemux::ScanVideoPacket(const uchar*, int, int, uchar&)' without object
make[1]: *** [xineDevice.o] Error 1

Is there any solution?
Please help me.

Regards,
AK
  

Reinhard Nissl wrote:
> Hi,
> 
> Reinhard Nissl wrote:
> 
>> The line will write the PES packet's content into file
>> /video/sample.es.h264 when a h264parser exists. Then please send me some
>> MB of the file.
> 
> The file you've sent me doesn't contain any useful data. You can have a
> look at it yourself:
> 
> od -Ax -t x1 -v sample2.es.h264 | less -S
> 
> You need to find at least the sequence 00 00 01. Otherwise it's garbage.
> 
> I'll go to bed soon, so here's a quick description how to go on:
> 
> - add this function to cRepacker
>   virtual void LogTS(const uint8_t *Buf) {}
> - add this function to cVideoRepacker
>   virtual void LogTS(const uint8_t *Buf) { if (h264parser) { static FILE
> *f = fopen("/video/sample.ts", "wb"); fwrite(Buf, 1, 188, f); fflush(f); } }
> - change this area in ts_to_pes() like that:
> 
> void cTS2PES::ts_to_pes(const uint8_t *Buf) // don't need count (=188)
> {
>   if (!Buf)
>      return;
> if (repacker) repacker->LogTS(Buf);
>   if (Buf[1] & TS_ERROR)
> 
> Be careful to just have a single cVideoRepacker instance write into this
> file, i. e. either activate transfer mode on this channel or make a
> recording on this channel but not both at the same time.
> 
> Have a look at this file with
> 
> od -Ax -t x1 -v -w188 sample.ts | less -S
> 
> and locate the sequence 00 00 01 multiple times. It should then be
> possible to record this channel although it doesn't work for now, as
> cVideoRepacker didn't find any startcode (00 00 01) in the
> sample.es.h264 from above.
> 
> Bye.

I have now tested when there is a program running (I am even seeing the 
dvb-subtitles with xineliboutput), but still there are no "00 00 01" 
series in the sample.ts. Anything more I could test with?

-Petri
  

On Thu, Aug 30, 2007 at 08:44:27PM +0300, Petri Helin wrote:
> I have now tested when there is a program running (I am even seeing the 
> dvb-subtitles with xineliboutput), but still there are no "00 00 01" 
> series in the sample.ts. Anything more I could test with?

I lost the stream also today. The subtitles were visible, but no sound.
vlc of course did not got anything to show.

After a several (10 - 15) try I did manage to tune to CD channel and got 
sound also using xineliboutput. After getting the sound I did try vlc
and got stream also. 

There is some problems on tuning or encrypting hd channels. Because I do 
have only budget cards without cams, my canal+ card is on my dbox2 and 
I'm using xx plugin to access the card. 

...hanu
  

Hannu Tirkkonen wrote:
> There is some problems on tuning or encrypting hd channels. 

Everything worked without problems when they used mpeg2 on Canal+ HD.

-Petri
  

Hi,

Petri Helin wrote:

> I have now tested when there is a program running (I am even seeing the 
> dvb-subtitles with xineliboutput), but still there are no "00 00 01" 
> series in the sample.ts. Anything more I could test with?

I'm sorry, I can't help you any further. Try to get a correctly
decrypted TS first, then it should work out of the box.

When you have a look at the first sample.ts you've sent me with this command

od -Ax -t x1 -v -w188 sample.ts | less -S

then you can find the sequence 00 00 01 09 which is a H.264 access unit
delimiter. So it once must have worked to get a properly decrypted TS.

Bye.
  

Reinhard Nissl wrote:
> Hi,
> 
> Reinhard Nissl wrote:
> 
> Have a look at this file with
> 
> od -Ax -t x1 -v -w188 sample.ts | less -S
> 
> and locate the sequence 00 00 01 multiple times. It should then be
> possible to record this channel although it doesn't work for now, as
> cVideoRepacker didn't find any startcode (00 00 01) in the
> sample.es.h264 from above.
> 
> Bye.

I tried again by using streamdev-plugin to send TS-stream to a vlc 
client, which I set to dump the TS-stream. In the dumped stream I can 
find the "00 00 01" start codes.

-Petri
  

Reinhard Nissl wrote:
> Hi,
> 
> Petri Helin wrote:
> 
>> I have now tested when there is a program running (I am even seeing the 
>> dvb-subtitles with xineliboutput), but still there are no "00 00 01" 
>> series in the sample.ts. Anything more I could test with?
> 
> I'm sorry, I can't help you any further. Try to get a correctly
> decrypted TS first, then it should work out of the box.
> 
> When you have a look at the first sample.ts you've sent me with this command
> 
> od -Ax -t x1 -v -w188 sample.ts | less -S
> 
> then you can find the sequence 00 00 01 09 which is a H.264 access unit
> delimiter. So it once must have worked to get a properly decrypted TS.
> 
> Bye.


When I tried again with streamdev-plugin sending TS-stream to a vlc 
client and letting it dump the TS-stream, I can find the "00 00 01 09" 
delimiter in the dumped stream. So if it works with the combination 
above, what could be missing from VDR itself that prevents it from doing 
the same?

-Petri
  

On Thu, Aug 30, 2007 at 12:05:08AM +0300, Hannu Tirkkonen wrote:
> I did apply this h264 patch and streamdev patch from: 
> http://www.vdr-developer.org/mantisbt/view.php?id=382
> 
> Now the load of the server is low when tuned to Canal+ HD and I can watch the stream using vlc.
> The recording at least outputs something to hard disk ;)

Well... the video part of the recordings seems to be corrupted.
vlc cannot show any video; there's only audio.

projectx says (hundreds of lines on 34MB recording):
!> error in pes_extension of pes-ID 0xBD @ pos: 112153 (1554 / 14 / 15 / true / false)
-> found PES-ID 0xBD (private stream 1) @ 112153
!> error in pes_extension of pes-ID 0xE0 @ pos: 134640 (2048 / 14 / 15 / true / false)
!> error in pes_extension of pes-ID 0xE0 @ pos: 188715 (2048 / 14 / 15 / true / false)
!> error in pes_extension of pes-ID 0xE0 @ pos: 247087 (2048 / 19 / 20 / true / false)
....
-> more than 500 warnings/errors, stop logging..
-> dropping video data, GOP larger than 6MB
-> dropping video data, GOP larger than 6MB

od does find 00 00 01 09 sequences from the file.

The live stream can be watched with vlc, and saving 
the stream with vlc creates a file that can be watched again with mplayer or vlc.

There is 34MB of the recording on http://hotel.hanu.com/~hanu/h264

...hanu
  

On Fri, Aug 31, 2007 at 12:05:12AM +0300, Petri Helin wrote:
> 
> When I tried again with streamdev-plugin sending TS-stream to a vlc 
> client and letting it dump the TS-stream, I can find the "00 00 01 09" 
> delimiter in the dumped stream. So if it works with the combination 
> above, what could be missing from VDR itself that prevents it from doing 
> the same?

Maybe there is something to do with the Welho's way of broadcasting
the Canal+ HD dvb-s2 stream again in dvb-c?

I do have a subscription also on Thor 1W, so I'll try to do some
tests using dvb-s2 during the weekend.

(The dish splitter is on another room, so there can be some
waf negotiations during the weekend ;)) 

..hanu
  

El Jueves, 30 de Agosto de 2007, Hannu Tirkkonen escribió:
> On Thu, Aug 30, 2007 at 12:05:08AM +0300, Hannu Tirkkonen wrote:
> > I did apply this h264 patch and streamdev patch from:
> > http://www.vdr-developer.org/mantisbt/view.php?id=382
> >
> > Now the load of the server is low when tuned to Canal+ HD and I can watch
> > the stream using vlc. The recording at least outputs something to hard
> > disk ;)
>
> Well... the video part of the recordings seems to be corrupted.
> vlc cannot show any video; there's only audio.
>
> projectx says (hundreds of lines on 34MB recording):
> !> error in pes_extension of pes-ID 0xBD @ pos: 112153 (1554 / 14 / 15 /
> true / false) -> found PES-ID 0xBD (private stream 1) @ 112153
> !> error in pes_extension of pes-ID 0xE0 @ pos: 134640 (2048 / 14 / 15 /
> true / false) !> error in pes_extension of pes-ID 0xE0 @ pos: 188715 (2048
> / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xE0 @ pos:
> 247087 (2048 / 19 / 20 / true / false) ....

I have this errors also with the ttxtsubs .They are not important in mpeg-2 
streams. Perhaps ttxtsubs corupts the mpeg-4 stream.

Jose Alberto

> -> more than 500 warnings/errors, stop logging..
> -> dropping video data, GOP larger than 6MB
> -> dropping video data, GOP larger than 6MB
>
> od does find 00 00 01 09 sequences from the file.
>
> The live stream can be watched with vlc, and saving
> the stream with vlc creates a file that can be watched again with mplayer
> or vlc.
>
> There is 34MB of the recording on http://hotel.hanu.com/~hanu/h264
>
> ...hanu
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

Hi,

Arthur Konovalov wrote:

> I trying to compile vdr-1.5.9 with h264 patches but vdr-xine-0.7.10 plugin give 
> me error:
> 
> xineDevice.c: In member function 'int PluginXine::cXineDevice::PlayCommon3(const 
> uchar*, int, int64_t)':
> xineDevice.c:1387: error: cannot call member function 'int 
> cRemux::ScanVideoPacket(const uchar*, int, int, uchar&)' without object
> xineDevice.c: In function 'bool PluginXine::getPTS(const uchar*, int, int64_t&, 
> bool, bool, double&, double&, double&, double&, double*)':
> xineDevice.c:2017: error: cannot call member function 'int 
> cRemux::ScanVideoPacket(const uchar*, int, int, uchar&)' without object
> make[1]: *** [xineDevice.o] Error 1
> 
> Is there any solution?

Use vdr-xine-0.7.11 please.

Bye.
  

Hi,

Hannu Tirkkonen wrote:

> Well... the video part of the recordings seems to be corrupted.
> vlc cannot show any video; there's only audio.
> 
> projectx says (hundreds of lines on 34MB recording):
> !> error in pes_extension of pes-ID 0xBD @ pos: 112153 (1554 / 14 / 15 / true / false)
> -> found PES-ID 0xBD (private stream 1) @ 112153
> !> error in pes_extension of pes-ID 0xE0 @ pos: 134640 (2048 / 14 / 15 / true / false)
> !> error in pes_extension of pes-ID 0xE0 @ pos: 188715 (2048 / 14 / 15 / true / false)
> !> error in pes_extension of pes-ID 0xE0 @ pos: 247087 (2048 / 19 / 20 / true / false)
> ....
> -> more than 500 warnings/errors, stop logging..
> -> dropping video data, GOP larger than 6MB
> -> dropping video data, GOP larger than 6MB

ProjectX doesn't understand H.264. It assumes MPEG2 and therefore sees
an overfull GOP.

> od does find 00 00 01 09 sequences from the file.
> 
> The live stream can be watched with vlc, and saving 
> the stream with vlc creates a file that can be watched again with mplayer or vlc.
> 
> There is 34MB of the recording on http://hotel.hanu.com/~hanu/h264

Plays perfectly here with vdr-xine-0.7.11 and xine-lib-cvs from my
homepage + vdr-xine's xine-lib.patch. If I play it in slow motion, my PC
is fast enough to decode and display all frames.

Bye.
  

Hi,

Hannu Tirkkonen wrote:

>> When I tried again with streamdev-plugin sending TS-stream to a vlc 
>> client and letting it dump the TS-stream, I can find the "00 00 01 09" 
>> delimiter in the dumped stream. So if it works with the combination 
>> above, what could be missing from VDR itself that prevents it from doing 
>> the same?
> 
> Maybe there is something to do with the Welho's way of broadcasting
> the Canal+ HD dvb-s2 stream again in dvb-c?
> 
> I do have a subscription also on Thor 1W, so I'll try to do some
> tests using dvb-s2 during the weekend.

Please keep in mind, that my patch doesn't add DVB-S2 support.

Bye.
  

On 8/29/07, Reinhard Nissl <rnissl@gmx.de> wrote:
> Hi,
>
> the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
>
> These changes should make VDR ready for the upcoming IFA fair in regard
> to the broadcasts on the temporary channel EinsFestival HD.
>

Referring to the problems I've had with this patch, I'd like to know
if the reason was that the channel I'm trying to watch/record is
encrypted. Have you had chance to test this with an encrypted channel?
Or is that out of the question and the reason is something else?

-Petri
  

Hi,

Petri Helin wrote:

>> the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
>>
>> These changes should make VDR ready for the upcoming IFA fair in regard
>> to the broadcasts on the temporary channel EinsFestival HD.
> 
> Referring to the problems I've had with this patch, I'd like to know
> if the reason was that the channel I'm trying to watch/record is
> encrypted. Have you had chance to test this with an encrypted channel?

No, I didn't have a chance to test this.

> Or is that out of the question and the reason is something else?

One part of my patch adds some functionality to cVideoRepacker and
therefore has no influence on the TS level.

But another part modifies VPID to transport the information that this
channel uses H.264. This is done by adding 10000 to the normal VPID
which is in the range 0..8191. The decimal offset 10000 was chosen over
the hex offset 0x10000 as the real VPID should still be recognizable in
channels.conf without using a calculator.

The drawback is, that the decimal offset isn't simply clipped away by
assigning the patched VPID for example to a variable of type short or
when masking it with 0x1fff. Therefore it is necessary to add some
special clipping code at each location where the patched VPID is entered
into some data structure which is then given to DVB API functions.

So, there is the chance that this clipping is missing at a location
where the VPID is scheduled for decrypting. This could be the reason why
the video TS packets do not get decrypted.

But I don't understand why streamdev still delivers a decrypted video
stream in that case. Can it be that the client asks streamdev to filter
certain TS packets and therefore uses the correct VPID?

Bye.
  

Reinhard Nissl wrote:
> But I don't understand why streamdev still delivers a decrypted video
> stream in that case. Can it be that the client asks streamdev to filter
> certain TS packets and therefore uses the correct VPID?

Yes. In http streaming mode streamdev parses PIDs directly from PMT and
does not use VDR channel data. But the VDR<->VDR streaming mode probably
does not work if PIDs are not "real" ones.


- Petri