Hello,

I was using the MPEG-CENC encryption method and notice the output was equal when giving an IV of 64-bit and 128-bit (while writing the ticket I notice this would happen even if padding 0s were not added).
I used the commands:
mp4encrypt --method MPEG-CENC --key 201:594b01e0aa0632b0aac7339d3703b2ce:**ecabaeaada0412d4** --property 201:KID:ac676b195d71347ba9ad77ea61d59ed7 --fragments-info Header.m4s video.m4s video_64bit.m4s

mp4encrypt --method MPEG-CENC --key 201:594b01e0aa0632b0aac7339d3703b2ce:**ecabaeaada0412d49425d166ab49a263** --property 201:KID:ac676b195d71347ba9ad77ea61d59ed7 --fragments-info Header.m4s video.m4s video_128bit.m4s

Taking a look into the senc box inside the segment I found the IV defined there was ecabaeaada0412d40000000000000000 for both outputs.
From the mp4encrypt page it is written:
    _OMA-PDCF-CTR, ISMA-IAEC, PIFF-CTR, **MPEG-CENC**, MPEG-CENS:
    the <iv> should be a 64-bit hex string.
    If a 128-bit value is supplied, it will be truncated to 64-bit._

This part seems correct since it ignores the last 64bits of the IV, but than it seems to pad the IVs with 0s as if it was one of these methods:
    _OMA-PDCF-CBC, MARLIN-IPMP-ACBC, MARLIN-IPMP-ACGK, PIFF-CBC, MPEG-CBC1, MPEG-CBCS: 
    the <iv> can be 64-bit or 128-bit
    If the IV is specified as a 64-bit value, it will be padded with zeros._

The 0s are forcing the IV to be 128bit all the time, which can break the decryption if it only supports 64bit IVs (I believe the truncating was because of that).
Added both segment files so you can check.
[video_128bit.zip](https://github.com/axiomatic-systems/Bento4/files/8178572/video_128bit.zip)

Hope it helps.
mp4encrypt is padding 64-bit IVs with 0s on MPEG-CENC
This is a GitHub Issue
repo:Bento4
owner:axiomatic-systems
Title : mp4encrypt is padding 64-bit IVs with 0s on MPEG-CENC
Issue date:

--- start body ---
Hello,

I was using the MPEG-CENC encryption method and notice the output was equal when giving an IV of 64-bit and 128-bit (while writing the ticket I notice this would happen even if padding 0s were not added).
I used the commands:
mp4encrypt --method MPEG-CENC --key 201:594b01e0aa0632b0aac7339d3703b2ce:**ecabaeaada0412d4** --property 201:KID:ac676b195d71347ba9ad77ea61d59ed7 --fragments-info Header.m4s video.m4s video_64bit.m4s

mp4encrypt --method MPEG-CENC --key 201:594b01e0aa0632b0aac7339d3703b2ce:**ecabaeaada0412d49425d166ab49a263** --property 201:KID:ac676b195d71347ba9ad77ea61d59ed7 --fragments-info Header.m4s video.m4s video_128bit.m4s

Taking a look into the senc box inside the segment I found the IV defined there was ecabaeaada0412d40000000000000000 for both outputs.
From the mp4encrypt page it is written:
    _OMA-PDCF-CTR, ISMA-IAEC, PIFF-CTR, **MPEG-CENC**, MPEG-CENS:
    the <iv> should be a 64-bit hex string.
    If a 128-bit value is supplied, it will be truncated to 64-bit._

This part seems correct since it ignores the last 64bits of the IV, but than it seems to pad the IVs with 0s as if it was one of these methods:
    _OMA-PDCF-CBC, MARLIN-IPMP-ACBC, MARLIN-IPMP-ACGK, PIFF-CBC, MPEG-CBC1, MPEG-CBCS: 
    the <iv> can be 64-bit or 128-bit
    If the IV is specified as a 64-bit value, it will be padded with zeros._

The 0s are forcing the IV to be 128bit all the time, which can break the decryption if it only supports 64bit IVs (I believe the truncating was because of that).
Added both segment files so you can check.
[video_128bit.zip](https://github.com/axiomatic-systems/Bento4/files/8178572/video_128bit.zip)

Hope it helps.
--- end body ---
