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. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
