Enabling the CBCS encryption of multiple block concurrently

[rbouqueau]

• Plug at cenc_encrypt_packet() or even better at gf_crypt_encrypt(). The latter option seems simpler: gf_crypt_encrypt(cstr->keys[0].crypt, output, pck_size - clear_trailing); can be replaced by queue_job();. We don't seem to use the data afterward (tests will tell ;) ).
• Pre-allocate the output packet.
• NB: bs_r is put in the context to avoir dynamic allocations only.
• Don't forget to ask for a reference of the input packet (to avoid input data to be freed/recycled before complete use). Once complete send the output packet.

[mdcornu]

Hi Romain,

Some questions about your post above:

• What do you meant to pre-allocate the output packet?
  In cenc_encrypt_packet() there is dst_pck = gf_filter_pck_new_clone(cstr->opid, pck, &output); Do you meant to use gf_filter_pck_new_alloc() instead? Or is there a command line option that will do pre-allocation?
• ask for a reference of the input packet
  Do I need to keep a reference to the input packet even after the output packet has been cloned?

Command used for testing purposes:
MP4Box -for-test -crypt cbcs_const.xml -out ./output/encrypted.mp4 ./example.mp4

Proposed changes could be something like:

• Update GF_Crypt struct with the following (accessible via GF_CENCStream->crypt) in cenc module
  • ipsec-mb scheduler reference
  • new function get_completed_packet to return already encrypted packet
  • new function flush_packet to force next packet to be encrypted and returned
• Update cenc_encrypt_packet() to
  • get reference to packet (dst/opid) -- should I keep reference to input packet too?
  • enqueue packet for encryption
  • check for completed (encrypted) packets
    • if there is a completed packet then call gf_filter_pck_send(completed_pck) and release reference
    • Note: there will be a minimum of 16 packets enqueued before any are completed
• Update cenc_enc_process() to
  • flush and send all remaining packets on PID EOS

Let me know if you see anything issues with this approach.

Thanks!

[rbouqueau]

Hi Romain,

Some questions about your post above:

* What do you meant to pre-allocate the output packet?
  In cenc_encrypt_packet() there is `dst_pck = gf_filter_pck_new_clone(cstr->opid, pck, &output);` Do you meant to use `gf_filter_pck_new_alloc()` instead? Or is there a command line option that will do pre-allocation?

Use gf_filter_pck_new_alloc() to allocate a new packet.

* **ask for a reference of the input packet**
  Do I need to keep a reference to the input packet even after the output packet has been cloned?

cloned -> allocated

Yes. You need to keep the reference to the input until you don't need the input anymore. Not before.

Command used for testing purposes: MP4Box -for-test -crypt cbcs_const.xml -out ./output/encrypted.mp4 ./example.mp4

Yes. In this case you won't be threaded. To run the encryption in a loop alone in its thread use gpac -threads=-1 -i ./example.mp4@ cecrypt:cfile=cbcs_const.xml @ -o ./output/encrypted.mp4 instead.

Proposed changes could be something like:

* Update GF_Crypt struct with the following (accessible via GF_CENCStream->crypt) in cenc module
  
  * ipsec-mb scheduler reference
  * new function `get_completed_packet` to return already encrypted packet
  * new function `flush_packet` to force next packet to be encrypted and returned

* Update `cenc_encrypt_packet()` to
  
  * get reference to packet (dst/opid) -- should I keep reference to input packet too?

Yes as long as the input data needs to be accessed (e.g. you haven't copied it, etc.).

  * enqueue packet for encryption
  * check for completed (encrypted) packets
    
    * if there is a completed packet then call `gf_filter_pck_send(completed_pck)` and release reference
    * Note: there will be a minimum of 16 packets enqueued before any are completed

Yes. I assume the calling order is kept ; other we need to reorder the packets.

* Update `cenc_enc_process()` to
  
  * flush and send all remaining packets on PID EOS

Seems like a good approach. Let me know if you need anything from us.

[mdcornu]

Thanks for the clarifications, I'll let you know if I run into any issues.

-Marcel