When specifying an IV length of 8-bytes in my encrypt.xml (using saiSavedBox type of 'senc'), MP4Box is writing a 16-byte IVs to the 'senc' box (with lower 8-bytes written as 0).
I will work on a patch if you don't get to it first.
Some initial thoughts as I work through trying to fix this. I don't think we can use the standard functions ("senc_New", "senc_Read", "senc_Write") with the 'senc' box the same way we do with all other boxes.
The 'senc' box does not have fixed sizes for all fields. The length of the IV field is determined by something outside of the 'senc' box. So, I'm thinking we may need unique functions that take the IV_size as a parameter so that we read/write the proper amount of data to/from the bitstream.
Last edit: Greg Rutz 2014-01-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also noticed that when converting the 8-byte IV into a 16-byte IV/BlockCounter as required by the CENC spec, the memset at ismacryp.c:1201 is initializing the BlockCounter portion to '0' (the ascii character 0) instead of the value 0.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The really tricky part of this fix is when loading ISO files. The parsing code just looks for the box type and calls gf_isom_box_new/gf_isom_box_read. But in the case of SENC and UUID_PSEC(flags==0), you need the associated 'tenc' box from the track in order to know the IV_size and properly parse the input bitstream.
The solution I'm looking at involves reading these 2 boxes "partially" at first. Meaning, you parse everything up to the subsample array, then you store the rest of the box data in a data array (inside the box struct) for complete parsing later. Then, I would have to find the correct place(s) in the code (maybe in gf_isom_parse_movie_boxes?) to insert a new function call that takes place after the file has been completely parsed and uses the IV_size from the 'tenc' and finishes parsing the SENC or PSEC using that information.
Any thoughts on whether that sounds like the right way to go about this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have found one bug in the rev 5043 fix for this issue. See the attached patch.
Also, via code inspection, I see the following lines of code that could be problematic. They are not currently causing me problems, but I'm not sure if they need to be considered as part of a complete fix.
Some initial thoughts as I work through trying to fix this. I don't think we can use the standard functions ("senc_New", "senc_Read", "senc_Write") with the 'senc' box the same way we do with all other boxes.
The 'senc' box does not have fixed sizes for all fields. The length of the IV field is determined by something outside of the 'senc' box. So, I'm thinking we may need unique functions that take the IV_size as a parameter so that we read/write the proper amount of data to/from the bitstream.
Last edit: Greg Rutz 2014-01-31
I also noticed that when converting the 8-byte IV into a 16-byte IV/BlockCounter as required by the CENC spec, the memset at ismacryp.c:1201 is initializing the BlockCounter portion to '0' (the ascii character 0) instead of the value 0.
The really tricky part of this fix is when loading ISO files. The parsing code just looks for the box type and calls gf_isom_box_new/gf_isom_box_read. But in the case of SENC and UUID_PSEC(flags==0), you need the associated 'tenc' box from the track in order to know the IV_size and properly parse the input bitstream.
The solution I'm looking at involves reading these 2 boxes "partially" at first. Meaning, you parse everything up to the subsample array, then you store the rest of the box data in a data array (inside the box struct) for complete parsing later. Then, I would have to find the correct place(s) in the code (maybe in gf_isom_parse_movie_boxes?) to insert a new function call that takes place after the file has been completely parsed and uses the IV_size from the 'tenc' and finishes parsing the SENC or PSEC using that information.
Any thoughts on whether that sounds like the right way to go about this?
rev 5043 should have now accept non-16 long IV and be more compliant to cenc when partial encryption is used. Could you check that out ?
I have also implemented a fix that I have been using. I will try to get around to testing the fix in SVN later this week.
I have found one bug in the rev 5043 fix for this issue. See the attached patch.
Also, via code inspection, I see the following lines of code that could be problematic. They are not currently causing me problems, but I'm not sure if they need to be considered as part of a complete fix.
src/isomedia/track.c:763
src/isomedia/drm_sample.c:1169
src/isomedia/box_code_drm.c:1186
I think the piff_psec_Write() function definitely needs to be updated to use the real IV_size.
G
This should have been fixed on SVN, could you check it out ?
Yes. Working well now. Thank you! OK to close.