mdcornu / gpac

Modular Multimedia framework for packaging, streaming and playing your favorite content.
http://gpac.io
GNU Lesser General Public License v2.1
1 stars 0 forks source link

Enabling the CBCS encryption of multiple block concurrently #1

Open rbouqueau opened 2 years ago

rbouqueau commented 2 years ago
mdcornu commented 2 years ago

Hi Romain,

Some questions about your post above:

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

Proposed changes could be something like:

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

Thanks!

rbouqueau commented 2 years ago

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 commented 2 years ago

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

-Marcel