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?
Dipl.-Inform. (FH) Reinhard Nissl
vdr mailing list