Is it possible that gsth264parser and gsth265parser parse encrypted nal data(header isn't encrypted)?

I wanna make pipeline for secure video path and use gsth264parser, gsth265parser.
example :
appsrc → qtdemux → cencdrm → h264parser → videodecryptor → videodecoder…
video data isn’t decrypted in cencdrm plugin. (passthrough)

I suppose you can make one of your own - however no security promises. A couple of things I would check are:

  • Emulation prevention bytes. These may break your NAL unit post-encryption, making the stream unplayable.
  • gst h264/h265 nal parser for accessing nal units to encode without breaking h264 stream itself.
  • Possible attacks on the encrypted stream. It may be possible to partially or completely retrieve what is in the video.

The hardest part is ensuring the security of the video encryptor i think. The rest can be easily achieved.

There should be many existent solutions for similar tasks i think but unfortunately I do not know any.

Thank you kindly reply.
Actually I concerned about below case.

Pre-condition : input nal header isn’t encrypted
input : encryped h264 AVC format data → h264 parser → output : encrypted h264 AnnexB format data

Could you give your opinion on whether there will be any problems with the operation of the h264 parser in the case above?

Honestly, I am not very knowledgable about how AVC ↔ AnnexB conversion works. The following are just my guesses.

If the encrypted NAL unit contents (data, not the header) do not change after the conversion, it should work. I quickly looked at the differences between them, and saw that they both use emulation 3 bytes (h.265 - do you need remove emulation prevention bytes of H.264 stream in AVCC or HVCC format? - Stack Overflow) thus there should not be an issue because of them.

On the other hand, there seems to be other differences between them (video streaming - what the advantage of h264 Annex-B VS AVCC - Stack Overflow) but then again, we are discussing only encrypting the video data, thus everything else should remain intact and GStreamer h264parse should be able to do its work.

I think it is worth a shot. I would love to try this some time.

Widevine and Playready works by encrypting the entropy coded part of the stream, and I’m pretty sure it’s being de-emulated (and that decrypters takes care of removing the post encryption de-emulation bytes). Small clarification about AVCc, the inner data is still de-emulated.

Thank you for your kind responses.
As per your suggestion, I plan to give it a try first.

To explain the current situation, we are delivering H264 data in AVCC format encrypted with PlayReady DRM from the Player. However, the video decoder needs to receive data in AnnexB format, which includes a start code. Therefore, we are in a situation where we need to parse the data in AVCC format and convert it to AnnexB format. However, because we can’t decrypt in the user area for security reasons, we have to parse and convert the encrypted data.

The biggest concern is whether there is a part in gsth264parser that references the nal payload, not the nal header. Could I get your opinion on this?

gst_h264_parser_identify_nalu_avc function can be used to get GstH264NalUnit struct which has “data” field, which is what you are looking for.

I’d need to check, but at least with widewine encryption it is not an issue to convert the stream format before the decrypter.

So starting from Playready 3, common encryption is used.


Subsample encryption is specified for NAL structured video, such as AVC and HEVC, to enable normal
processing and editing of video elementary streams prior to decryption.

The MPEG codecs specifications are not public, but the VP8/9 spec illustrate the method quite well: