[FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.

[Jacob Trimble]

- Parse schm atom to get different encryption schemes.
- Allow senc atom to appear in track fragments.
- Allow 16-byte IVs.
- Allow constant IVs (specified in tenc).
- Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
- Use sample descriptor to detect clear fragments.

This doesn't support:
- Different sample descriptor holding different encryption info.
- Only first sample descriptor can be encrypted.
- Encrypted sample groups (i.e. seig).
- Non-'cenc' encryption scheme when using -decryption_key.

This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.

Signed-off-by: Jacob Trimble <***@google.com>
---
libavformat/isom.h | 20 +-
libavformat/mov.c | 404 +++++++++++++++++++++------------
libavutil/aes_ctr.c | 11 +-
libavutil/aes_ctr.h | 4 +-
libavutil/encryption_info.c | 17 ++
libavutil/encryption_info.h | 6 +
libavutil/tests/aes_ctr.c | 2 +-
tests/fate/mov.mak | 8 +
tests/ref/fate/mov-frag-encrypted | 57 +++++
tests/ref/fate/mov-tenc-only-encrypted | 57 +++++
10 files changed, 426 insertions(+), 160 deletions(-)
create mode 100644 tests/ref/fate/mov-frag-encrypted
create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 65676fb0f5..3794b1f0fd 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -27,6 +27,7 @@
#include <stddef.h>
#include <stdint.h>

+#include "libavutil/encryption_info.h"
#include "libavutil/mastering_display_metadata.h"
#include "libavutil/spherical.h"
#include "libavutil/stereo3d.h"
@@ -108,12 +109,20 @@ typedef struct MOVSbgp {
unsigned int index;
} MOVSbgp;

+typedef struct MOVEncryptionIndex {
+ // Individual encrypted samples. If there are no elements, then the default
+ // settings will be used.
+ unsigned int nb_encrypted_samples;
+ AVEncryptionInfo **encrypted_samples;
+} MOVEncryptionIndex;
+
typedef struct MOVFragmentStreamInfo {
int id;
int64_t sidx_pts;
int64_t first_tfra_pts;
int64_t tfdt_dts;
int index_entry;
+ MOVEncryptionIndex *encryption_index;
} MOVFragmentStreamInfo;

typedef struct MOVFragmentIndexItem {
@@ -214,15 +223,10 @@ typedef struct MOVStreamContext {

int has_sidx; // If there is an sidx entry for this stream.
struct {
- int use_subsamples;
- uint8_t* auxiliary_info;
- uint8_t* auxiliary_info_end;
- uint8_t* auxiliary_info_pos;
- uint8_t auxiliary_info_default_size;
- uint8_t* auxiliary_info_sizes;
- size_t auxiliary_info_sizes_count;
- int64_t auxiliary_info_index;
struct AVAESCTR* aes_ctr;
+ unsigned int per_sample_iv_size; // Either 0, 8, or 16.
+ AVEncryptionInfo *default_encrypted_sample;
+ MOVEncryptionIndex *encryption_index;
} cenc;
} MOVStreamContext;

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 22faecfc17..eb3fb71e2a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1324,6 +1324,7 @@ static int update_frag_index(MOVContext *c, int64_t offset)
frag_stream_info[i].tfdt_dts = AV_NOPTS_VALUE;
frag_stream_info[i].first_tfra_pts = AV_NOPTS_VALUE;
frag_stream_info[i].index_entry = -1;
+ frag_stream_info[i].encryption_index = NULL;
}

if (index < c->frag_index.nb_items)
@@ -5710,117 +5711,224 @@ static int mov_read_frma(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0;
}

-static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+/**
+ * Gets the current encryption info and associated current stream context. If
+ * we are parsing a track fragment, this will return the specific encryption
+ * info for this fragment; otherwise this will return the global encryption
+ * info for the current stream.
+ */
+static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encryption_index, MOVStreamContext **sc)
{
+ MOVFragmentStreamInfo *frag_stream_info;
AVStream *st;
- MOVStreamContext *sc;
- size_t auxiliary_info_size;
+ int i;

- if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
- return 0;
+ frag_stream_info = get_current_frag_stream_info(&c->frag_index);
+ if (frag_stream_info) {
+ for (i = 0; i < c->fc->nb_streams; i++) {
+ if (c->fc->streams[i]->id == frag_stream_info->id) {
+ st = c->fc->streams[i];
+ break;
+ }
+ }
+ if (i == c->fc->nb_streams)
+ return 0;
+ *sc = st->priv_data;

- st = c->fc->streams[c->fc->nb_streams - 1];
- sc = st->priv_data;
+ if (!frag_stream_info->encryption_index) {
+ frag_stream_info->encryption_index = av_mallocz(sizeof(MOVEncryptionIndex));
+ if (!frag_stream_info->encryption_index)
+ return AVERROR(ENOMEM);
+ }
+ *encryption_index = frag_stream_info->encryption_index;
+ return 1;
+ } else {
+ // No current track fragment, using stream level encryption info.

- if (sc->cenc.aes_ctr) {
- av_log(c->fc, AV_LOG_ERROR, "duplicate senc atom\n");
- return AVERROR_INVALIDDATA;
+ if (c->fc->nb_streams < 1)
+ return 0;
+ st = c->fc->streams[c->fc->nb_streams - 1];
+ *sc = st->priv_data;
+
+ if (!(*sc)->cenc.encryption_index) {
+ (*sc)->cenc.encryption_index = av_mallocz(sizeof(MOVEncryptionIndex));
+ if (!(*sc)->cenc.encryption_index)
+ return AVERROR(ENOMEM);
+ }
+
+ *encryption_index = (*sc)->cenc.encryption_index;
+ return 1;
}
+}

- avio_r8(pb); /* version */
- sc->cenc.use_subsamples = avio_rb24(pb) & 0x02; /* flags */
+static int mov_read_sample_encryption_info(MOVContext *c, AVIOContext *pb, MOVStreamContext *sc, AVEncryptionInfo **sample, int use_subsamples)
+{
+ int i;
+ unsigned int subsample_count;
+ AVSubsampleEncryptionInfo *subsamples;

- avio_rb32(pb); /* entries */
+ *sample = av_encryption_info_clone(sc->cenc.default_encrypted_sample);
+ if (!*sample)
+ return AVERROR(ENOMEM);

- if (atom.size < 8 || atom.size > FFMIN(INT_MAX, SIZE_MAX)) {
- av_log(c->fc, AV_LOG_ERROR, "senc atom size %"PRId64" invalid\n", atom.size);
- return AVERROR_INVALIDDATA;
+ if (sc->cenc.per_sample_iv_size != 0) {
+ if (avio_read(pb, (*sample)->iv, sc->cenc.per_sample_iv_size) != sc->cenc.per_sample_iv_size) {
+ av_log(c->fc, AV_LOG_ERROR, "failed to read the initialization vector");
+ return AVERROR_INVALIDDATA;
+ }
}

- /* save the auxiliary info as is */
- auxiliary_info_size = atom.size - 8;
+ if (use_subsamples) {
+ subsample_count = avio_rb16(pb);

- sc->cenc.auxiliary_info = av_malloc(auxiliary_info_size);
- if (!sc->cenc.auxiliary_info) {
- return AVERROR(ENOMEM);
+ subsamples = av_realloc((*sample)->subsamples, sizeof(AVSubsampleEncryptionInfo) * subsample_count);
+ if (!subsamples) {
+ av_encryption_info_free(*sample);
+ return AVERROR(ENOMEM);
+ }
+ (*sample)->subsamples = subsamples;
+ (*sample)->subsample_count = subsample_count;
+
+ for (i = 0; i < subsample_count; i++) {
+ (*sample)->subsamples[i].bytes_of_clear_data = avio_rb16(pb);
+ (*sample)->subsamples[i].bytes_of_protected_data = avio_rb32(pb);
+ }
}

- sc->cenc.auxiliary_info_end = sc->cenc.auxiliary_info + auxiliary_info_size;
- sc->cenc.auxiliary_info_pos = sc->cenc.auxiliary_info;
- sc->cenc.auxiliary_info_index = 0;
+ return 0;
+}

- if (avio_read(pb, sc->cenc.auxiliary_info, auxiliary_info_size) != auxiliary_info_size) {
- av_log(c->fc, AV_LOG_ERROR, "failed to read the auxiliary info");
- return AVERROR_INVALIDDATA;
+static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+ MOVEncryptionIndex *encryption_index;
+ MOVStreamContext *sc;
+ int use_subsamples, ret;
+ unsigned int sample_count, i;
+
+ ret = get_current_encryption_info(c, &encryption_index, &sc);
+ if (ret != 1)
+ return ret;
+
+ if (encryption_index->nb_encrypted_samples) {
+ // This can happen if we have both saio/saiz and senc atoms.
+ av_log(c->fc, AV_LOG_DEBUG, "ignoring duplicate encryption info in senc\n");
+ return 0;
}

- /* initialize the cipher */
- sc->cenc.aes_ctr = av_aes_ctr_alloc();
- if (!sc->cenc.aes_ctr) {
+ avio_r8(pb); /* version */
+ use_subsamples = avio_rb24(pb) & 0x02; /* flags */
+
+ sample_count = avio_rb32(pb);
+
+ encryption_index->encrypted_samples = av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);
+ if (!encryption_index->encrypted_samples) {
return AVERROR(ENOMEM);
}
+ encryption_index->nb_encrypted_samples = sample_count;

- return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
+ for (i = 0; i < sample_count; i++) {
+ ret = mov_read_sample_encryption_info(c, pb, sc, &encryption_index->encrypted_samples[i], use_subsamples);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
}

-static int mov_read_saiz(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+static int mov_read_schm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
AVStream *st;
MOVStreamContext *sc;
- size_t data_size;
- int atom_header_size;
- int flags;

- if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
+ if (c->fc->nb_streams < 1)
return 0;
-
- st = c->fc->streams[c->fc->nb_streams - 1];
+ st = c->fc->streams[c->fc->nb_streams-1];
sc = st->priv_data;

- if (sc->cenc.auxiliary_info_sizes || sc->cenc.auxiliary_info_default_size) {
- av_log(c->fc, AV_LOG_ERROR, "duplicate saiz atom\n");
- return AVERROR_INVALIDDATA;
+ if (sc->pseudo_stream_id != 0) {
+ av_log(c->fc, AV_LOG_ERROR, "schm boxes are only supported in first sample descriptor\n");
+ return AVERROR_PATCHWELCOME;
}

- atom_header_size = 9;
-
- avio_r8(pb); /* version */
- flags = avio_rb24(pb);
+ if (atom.size < 8)
+ return AVERROR_INVALIDDATA;

- if ((flags & 0x01) != 0) {
- atom_header_size += 8;
+ avio_rb32(pb); /* version and flags */

- avio_rb32(pb); /* info type */
- avio_rb32(pb); /* info type param */
+ if (!sc->cenc.default_encrypted_sample) {
+ sc->cenc.default_encrypted_sample = av_encryption_info_alloc(0, 16, 16);
+ if (!sc->cenc.default_encrypted_sample) {
+ return AVERROR(ENOMEM);
+ }
}

- sc->cenc.auxiliary_info_default_size = avio_r8(pb);
- avio_rb32(pb); /* entries */
+ sc->cenc.default_encrypted_sample->scheme = avio_rl32(pb);
+ return 0;
+}

- if (atom.size <= atom_header_size) {
+static int mov_read_tenc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+ AVStream *st;
+ MOVStreamContext *sc;
+ unsigned int version, pattern, is_protected, iv_size;
+
+ if (c->fc->nb_streams < 1)
return 0;
+ st = c->fc->streams[c->fc->nb_streams-1];
+ sc = st->priv_data;
+
+ if (sc->pseudo_stream_id != 0) {
+ av_log(c->fc, AV_LOG_ERROR, "tenc atom are only supported in first sample descriptor\n");
+ return AVERROR_PATCHWELCOME;
}

- if (atom.size > FFMIN(INT_MAX, SIZE_MAX)) {
- av_log(c->fc, AV_LOG_ERROR, "saiz atom auxiliary_info_sizes size %"PRId64" invalid\n", atom.size);
- return AVERROR_INVALIDDATA;
+ if (!sc->cenc.default_encrypted_sample) {
+ sc->cenc.default_encrypted_sample = av_encryption_info_alloc(0, 16, 16);
+ if (!sc->cenc.default_encrypted_sample) {
+ return AVERROR(ENOMEM);
+ }
}

- /* save the auxiliary info sizes as is */
- data_size = atom.size - atom_header_size;
+ if (atom.size < 20)
+ return AVERROR_INVALIDDATA;

- sc->cenc.auxiliary_info_sizes = av_malloc(data_size);
- if (!sc->cenc.auxiliary_info_sizes) {
- return AVERROR(ENOMEM);
- }
+ version = avio_r8(pb); /* version */
+ avio_rb24(pb); /* flags */

- sc->cenc.auxiliary_info_sizes_count = data_size;
+ avio_r8(pb); /* reserved */
+ pattern = avio_r8(pb);
+
+ if (version > 0) {
+ sc->cenc.default_encrypted_sample->crypt_byte_block = pattern >> 4;
+ sc->cenc.default_encrypted_sample->skip_byte_block = pattern & 0xf;
+ }

- if (avio_read(pb, sc->cenc.auxiliary_info_sizes, data_size) != data_size) {
- av_log(c->fc, AV_LOG_ERROR, "failed to read the auxiliary info sizes");
+ is_protected = avio_r8(pb);
+ if (is_protected && !sc->cenc.encryption_index) {
+ // The whole stream should be by-default encrypted.
+ sc->cenc.encryption_index = av_mallocz(sizeof(MOVEncryptionIndex));
+ if (!sc->cenc.encryption_index)
+ return AVERROR(ENOMEM);
+ }
+ sc->cenc.per_sample_iv_size = avio_r8(pb);
+ if (avio_read(pb, sc->cenc.default_encrypted_sample->key_id, 16) != 16) {
+ av_log(c->fc, AV_LOG_ERROR, "failed to read the default key ID");
return AVERROR_INVALIDDATA;
}

+ if (is_protected && !sc->cenc.per_sample_iv_size) {
+ iv_size = avio_r8(pb);
+ if (iv_size != 8 && iv_size != 16) {
+ av_log(c->fc, AV_LOG_ERROR, "invalid default_constant_IV_size in tenc atom\n");
+ return AVERROR_INVALIDDATA;
+ }
+
+ if (avio_read(pb, sc->cenc.default_encrypted_sample->iv, iv_size) != iv_size) {
+ av_log(c->fc, AV_LOG_ERROR, "failed to read the default IV");
+ return AVERROR_INVALIDDATA;
+ }
+ }
+
return 0;
}

@@ -5861,108 +5969,103 @@ static int mov_read_dfla(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0;
}

-static int mov_seek_auxiliary_info(MOVContext *c, MOVStreamContext *sc, int64_t index)
+static int cenc_decrypt(MOVContext *c, MOVStreamContext *sc, AVEncryptionInfo *sample, uint8_t *input, int size)
{
- size_t auxiliary_info_seek_offset = 0;
- int i;
-
- if (sc->cenc.auxiliary_info_default_size) {
- auxiliary_info_seek_offset = (size_t)sc->cenc.auxiliary_info_default_size * index;
- } else if (sc->cenc.auxiliary_info_sizes) {
- if (index > sc->cenc.auxiliary_info_sizes_count) {
- av_log(c, AV_LOG_ERROR, "current sample %"PRId64" greater than the number of auxiliary info sample sizes %"SIZE_SPECIFIER"\n",
- index, sc->cenc.auxiliary_info_sizes_count);
- return AVERROR_INVALIDDATA;
- }
-
- for (i = 0; i < index; i++) {
- auxiliary_info_seek_offset += sc->cenc.auxiliary_info_sizes[i];
- }
- }
+ int i, ret;

- if (auxiliary_info_seek_offset > sc->cenc.auxiliary_info_end - sc->cenc.auxiliary_info) {
- av_log(c, AV_LOG_ERROR, "auxiliary info offset %"SIZE_SPECIFIER" greater than auxiliary info size %"SIZE_SPECIFIER"\n",
- auxiliary_info_seek_offset, (size_t)(sc->cenc.auxiliary_info_end - sc->cenc.auxiliary_info));
- return AVERROR_INVALIDDATA;
+ if (sample->scheme != MKTAG('c','e','n','c') || sample->crypt_byte_block != 0 || sample->skip_byte_block != 0) {
+ av_log(c->fc, AV_LOG_ERROR, "Only the 'cenc' encryption scheme is supported\n");
+ return AVERROR_PATCHWELCOME;
}

- sc->cenc.auxiliary_info_pos = sc->cenc.auxiliary_info + auxiliary_info_seek_offset;
- sc->cenc.auxiliary_info_index = index;
- return 0;
-}
-
-static int cenc_filter(MOVContext *c, MOVStreamContext *sc, int64_t index, uint8_t *input, int size)
-{
- uint32_t encrypted_bytes;
- uint16_t subsample_count;
- uint16_t clear_bytes;
- uint8_t* input_end = input + size;
- int ret;
+ if (!sc->cenc.aes_ctr) {
+ /* initialize the cipher */
+ sc->cenc.aes_ctr = av_aes_ctr_alloc();
+ if (!sc->cenc.aes_ctr) {
+ return AVERROR(ENOMEM);
+ }

- if (index != sc->cenc.auxiliary_info_index) {
- ret = mov_seek_auxiliary_info(c, sc, index);
+ ret = av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
if (ret < 0) {
return ret;
}
}

- /* read the iv */
- if (AES_CTR_IV_SIZE > sc->cenc.auxiliary_info_end - sc->cenc.auxiliary_info_pos) {
- av_log(c->fc, AV_LOG_ERROR, "failed to read iv from the auxiliary info\n");
- return AVERROR_INVALIDDATA;
- }
-
- av_aes_ctr_set_iv(sc->cenc.aes_ctr, sc->cenc.auxiliary_info_pos);
- sc->cenc.auxiliary_info_pos += AES_CTR_IV_SIZE;
+ av_aes_ctr_set_full_iv(sc->cenc.aes_ctr, sample->iv);

- if (!sc->cenc.use_subsamples)
+ if (!sample->subsample_count)
{
/* decrypt the whole packet */
av_aes_ctr_crypt(sc->cenc.aes_ctr, input, input, size);
return 0;
}

- /* read the subsample count */
- if (sizeof(uint16_t) > sc->cenc.auxiliary_info_end - sc->cenc.auxiliary_info_pos) {
- av_log(c->fc, AV_LOG_ERROR, "failed to read subsample count from the auxiliary info\n");
- return AVERROR_INVALIDDATA;
- }
-
- subsample_count = AV_RB16(sc->cenc.auxiliary_info_pos);
- sc->cenc.auxiliary_info_pos += sizeof(uint16_t);
-
- for (; subsample_count > 0; subsample_count--)
+ for (i = 0; i < sample->subsample_count; i++)
{
- if (6 > sc->cenc.auxiliary_info_end - sc->cenc.auxiliary_info_pos) {
- av_log(c->fc, AV_LOG_ERROR, "failed to read subsample from the auxiliary info\n");
- return AVERROR_INVALIDDATA;
- }
-
- /* read the number of clear / encrypted bytes */
- clear_bytes = AV_RB16(sc->cenc.auxiliary_info_pos);
- sc->cenc.auxiliary_info_pos += sizeof(uint16_t);
- encrypted_bytes = AV_RB32(sc->cenc.auxiliary_info_pos);
- sc->cenc.auxiliary_info_pos += sizeof(uint32_t);
-
- if ((uint64_t)clear_bytes + encrypted_bytes > input_end - input) {
+ if (sample->subsamples[i].bytes_of_clear_data + sample->subsamples[i].bytes_of_protected_data > size) {
av_log(c->fc, AV_LOG_ERROR, "subsample size exceeds the packet size left\n");
return AVERROR_INVALIDDATA;
}

/* skip the clear bytes */
- input += clear_bytes;
+ input += sample->subsamples[i].bytes_of_clear_data;
+ size -= sample->subsamples[i].bytes_of_clear_data;

/* decrypt the encrypted bytes */
- av_aes_ctr_crypt(sc->cenc.aes_ctr, input, input, encrypted_bytes);
- input += encrypted_bytes;
+ av_aes_ctr_crypt(sc->cenc.aes_ctr, input, input, sample->subsamples[i].bytes_of_protected_data);
+ input += sample->subsamples[i].bytes_of_protected_data;
+ size -= sample->subsamples[i].bytes_of_protected_data;
}

- if (input < input_end) {
+ if (size > 0) {
av_log(c->fc, AV_LOG_ERROR, "leftover packet bytes after subsample processing\n");
return AVERROR_INVALIDDATA;
}

- sc->cenc.auxiliary_info_index++;
+ return 0;
+}
+
+static int cenc_filter(MOVContext *mov, MOVStreamContext *sc, AVPacket *pkt, int current_index)
+{
+ MOVFragmentStreamInfo *frag_stream_info;
+ MOVEncryptionIndex *encryption_index;
+ AVEncryptionInfo *encrypted_sample;
+ int encrypted_index;
+
+ frag_stream_info = get_current_frag_stream_info(&mov->frag_index);
+ encrypted_index = current_index;
+ encryption_index = NULL;
+ if (frag_stream_info) {
+ // Note this only supports encryption info in the first sample descriptor.
+ if (mov->fragment.stsd_id == 1) {
+ if (frag_stream_info->encryption_index) {
+ encrypted_index = current_index - frag_stream_info->index_entry;
+ encryption_index = frag_stream_info->encryption_index;
+ } else {
+ encryption_index = sc->cenc.encryption_index;
+ }
+ }
+ } else {
+ encryption_index = sc->cenc.encryption_index;
+ }
+
+ if (encryption_index) {
+ if (!encryption_index->nb_encrypted_samples) {
+ // Full-sample encryption with default settings.
+ encrypted_sample = sc->cenc.default_encrypted_sample;
+ } else if (encrypted_index >= 0 && encrypted_index < encryption_index->nb_encrypted_samples) {
+ // Per-sample setting override.
+ encrypted_sample = encryption_index->encrypted_samples[encrypted_index];
+ } else {
+ av_log(mov->fc, AV_LOG_ERROR, "Incorrect number of samples in encryption info\n");
+ return AVERROR_INVALIDDATA;
+ }
+
+ if (mov->decryption_key) {
+ return cenc_decrypt(mov, sc, encrypted_sample, pkt->data, pkt->size);
+ }
+ }
+
return 0;
}

@@ -6091,7 +6194,9 @@ static const MOVParseTableEntry mov_default_parse_table[] = {
{ MKTAG('s','i','n','f'), mov_read_default },
{ MKTAG('f','r','m','a'), mov_read_frma },
{ MKTAG('s','e','n','c'), mov_read_senc },
-{ MKTAG('s','a','i','z'), mov_read_saiz },
+{ MKTAG('s','c','h','m'), mov_read_schm },
+{ MKTAG('s','c','h','i'), mov_read_default },
+{ MKTAG('t','e','n','c'), mov_read_tenc },
{ MKTAG('d','f','L','a'), mov_read_dfla },
{ MKTAG('s','t','3','d'), mov_read_st3d }, /* stereoscopic 3D video box */
{ MKTAG('s','v','3','d'), mov_read_sv3d }, /* spherical video box */
@@ -6477,6 +6582,16 @@ static int mov_read_timecode_track(AVFormatContext *s, AVStream *st)
return 0;
}

+static void mov_free_encryption_index(MOVEncryptionIndex **index) {
+ int i;
+ if (!index || !*index) return;
+ for (i = 0; i < (*index)->nb_encrypted_samples; i++) {
+ av_encryption_info_free((*index)->encrypted_samples[i]);
+ }
+ av_freep(&(*index)->encrypted_samples);
+ av_freep(index);
+}
+
static int mov_read_close(AVFormatContext *s)
{
MOVContext *mov = s->priv_data;
@@ -6519,8 +6634,8 @@ static int mov_read_close(AVFormatContext *s)
av_freep(&sc->extradata);
av_freep(&sc->extradata_size);

- av_freep(&sc->cenc.auxiliary_info);
- av_freep(&sc->cenc.auxiliary_info_sizes);
+ mov_free_encryption_index(&sc->cenc.encryption_index);
+ av_encryption_info_free(sc->cenc.default_encrypted_sample);
av_aes_ctr_free(sc->cenc.aes_ctr);

av_freep(&sc->stereo3d);
@@ -6545,6 +6660,10 @@ static int mov_read_close(AVFormatContext *s)
av_freep(&mov->bitrates);

for (i = 0; i < mov->frag_index.nb_items; i++) {
+ MOVFragmentStreamInfo *frag = mov->frag_index.item[i].stream_info;
+ if (frag) {
+ mov_free_encryption_index(&frag->encryption_index);
+ }
av_freep(&mov->frag_index.item[i].stream_info);
}
av_freep(&mov->frag_index.item);
@@ -7115,12 +7234,9 @@ static int mov_read_packet(AVFormatContext *s, AVPacket *pkt)
if (mov->aax_mode)
aax_filter(pkt->data, pkt->size, mov);

- if (sc->cenc.aes_ctr) {
- ret = cenc_filter(mov, sc, current_index, pkt->data, pkt->size);
- if (ret) {
- return ret;
- }
- }
+ ret = cenc_filter(mov, sc, pkt, current_index);
+ if (ret < 0)
+ return ret;

return 0;
}
diff --git a/libavutil/aes_ctr.c b/libavutil/aes_ctr.c
index e9c568fe0d..6ed69c8e10 100644
--- a/libavutil/aes_ctr.c
+++ b/libavutil/aes_ctr.c
@@ -38,10 +38,9 @@ struct AVAESCTR *av_aes_ctr_alloc(void)
return av_mallocz(sizeof(struct AVAESCTR));
}

-void av_aes_ctr_set_iv(struct AVAESCTR *a, const uint8_t* iv)
+void av_aes_ctr_set_full_iv(struct AVAESCTR *a, const uint8_t* iv)
{
- memcpy(a->counter, iv, AES_CTR_IV_SIZE);
- memset(a->counter + AES_CTR_IV_SIZE, 0, sizeof(a->counter) - AES_CTR_IV_SIZE);
+ memcpy(a->counter, iv, sizeof(a->counter));
a->block_offset = 0;
}

@@ -52,12 +51,14 @@ const uint8_t* av_aes_ctr_get_iv(struct AVAESCTR *a)

void av_aes_ctr_set_random_iv(struct AVAESCTR *a)
{
- uint32_t iv[2];
+ uint32_t iv[4];

iv[0] = av_get_random_seed();
iv[1] = av_get_random_seed();
+ iv[2] = 0;
+ iv[3] = 0;

- av_aes_ctr_set_iv(a, (uint8_t*)iv);
+ av_aes_ctr_set_full_iv(a, (uint8_t*)iv);
}

int av_aes_ctr_init(struct AVAESCTR *a, const uint8_t *key)
diff --git a/libavutil/aes_ctr.h b/libavutil/aes_ctr.h
index f596fa6a46..5995b37bec 100644
--- a/libavutil/aes_ctr.h
+++ b/libavutil/aes_ctr.h
@@ -67,9 +67,9 @@ const uint8_t* av_aes_ctr_get_iv(struct AVAESCTR *a);
void av_aes_ctr_set_random_iv(struct AVAESCTR *a);

/**
- * Forcefully change the iv
+ * Forcefully change the "full" 16-byte iv, including the counter
*/
-void av_aes_ctr_set_iv(struct AVAESCTR *a, const uint8_t* iv);
+void av_aes_ctr_set_full_iv(struct AVAESCTR *a, const uint8_t* iv);

/**
* Increment the top 64 bit of the iv (performed after each frame)
diff --git a/libavutil/encryption_info.c b/libavutil/encryption_info.c
index 76796b50ee..ad7ce3656a 100644
--- a/libavutil/encryption_info.c
+++ b/libavutil/encryption_info.c
@@ -59,6 +59,23 @@ AVEncryptionInfo *av_encryption_info_alloc(uint32_t subsample_count, uint32_t ke
return info;
}

+AVEncryptionInfo *av_encryption_info_clone(const AVEncryptionInfo *info)
+{
+ AVEncryptionInfo *ret;
+
+ ret = av_encryption_info_alloc(info->subsample_count, info->key_id_size, info->iv_size);
+ if (!ret)
+ return NULL;
+
+ ret->scheme = info->scheme;
+ ret->crypt_byte_block = info->crypt_byte_block;
+ ret->skip_byte_block = info->skip_byte_block;
+ memcpy(ret->iv, info->iv, info->iv_size);
+ memcpy(ret->key_id, info->key_id, info->key_id_size);
+ memcpy(ret->subsamples, info->subsamples, sizeof(AVSubsampleEncryptionInfo) * info->subsample_count);
+ return ret;
+}
+
void av_encryption_info_free(AVEncryptionInfo *info)
{
if (info) {
diff --git a/libavutil/encryption_info.h b/libavutil/encryption_info.h
index 6c2eee80f6..591ac14957 100644
--- a/libavutil/encryption_info.h
+++ b/libavutil/encryption_info.h
@@ -92,6 +92,12 @@ typedef struct AVEncryptionInfo {
*/
AVEncryptionInfo *av_encryption_info_alloc(uint32_t subsample_count, uint32_t key_id_size, uint32_t iv_size);

+/**
+ * Allocates an AVEncryptionInfo structure with a copy of the given data.
+ * @return The new AVEncryptionInfo structure, or NULL on error.
+ */
+AVEncryptionInfo *av_encryption_info_clone(const AVEncryptionInfo *info);
+
/**
* Frees the given encryption info object. This MUST NOT be used to free the
* side-data data pointer, that should use normal side-data methods.
diff --git a/libavutil/tests/aes_ctr.c b/libavutil/tests/aes_ctr.c
index c5ebeda7ac..00fdb05d13 100644
--- a/libavutil/tests/aes_ctr.c
+++ b/libavutil/tests/aes_ctr.c
@@ -45,7 +45,7 @@ int main (void)

av_aes_ctr_set_random_iv(ae);
iv = av_aes_ctr_get_iv(ae);
- av_aes_ctr_set_iv(ad, iv);
+ av_aes_ctr_set_full_iv(ad, iv);

av_aes_ctr_crypt(ae, tmp, plain, sizeof(tmp));
av_aes_ctr_crypt(ad, tmp, tmp, sizeof(tmp));
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 64f92e9488..90ee06a000 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -6,6 +6,8 @@ FATE_MOV = fate-mov-3elist \
fate-mov-1elist-ends-last-bframe \
fate-mov-2elist-elist1-ends-bframe \
fate-mov-3elist-encrypted \
+ fate-mov-frag-encrypted \
+ fate-mov-tenc-only-encrypted \
fate-mov-invalid-elst-entry-count \
fate-mov-gpmf-remux \
fate-mov-440hz-10ms \
@@ -37,6 +39,12 @@ fate-mov-3elist-1ctts: CMD = framemd5 -i $(TARGET_SAMPLES)/mov/mov-3elist-1ctts.
# Edit list with encryption
fate-mov-3elist-encrypted: CMD = framemd5 -decryption_key 12345678901234567890123456789012 -i $(TARGET_SAMPLES)/mov/mov-3elist-encrypted.mov

+# Fragmented encryption with senc boxes in movie fragments.
+fate-mov-frag-encrypted: CMD = framemd5 -decryption_key 12345678901234567890123456789012 -i $(TARGET_SAMPLES)/mov/mov-frag-encrypted.mp4
+
+# Full-sample encryption and constant IV using only tenc atom (no senc/saio/saiz).
+fate-mov-tenc-only-encrypted: CMD = framemd5 -decryption_key 12345678901234567890123456789012 -i $(TARGET_SAMPLES)/mov/mov-tenc-only-encrypted.mp4
+
# Makes sure that the CTTS is also modified when we fix avindex in mov.c while parsing edit lists.
fate-mov-elist-starts-ctts-2ndsample: CMD = framemd5 -i $(TARGET_SAMPLES)/mov/mov-elist-starts-ctts-2ndsample.mov

diff --git a/tests/ref/fate/mov-frag-encrypted b/tests/ref/fate/mov-frag-encrypted
new file mode 100644
index 0000000000..e6c109b566
--- /dev/null
+++ b/tests/ref/fate/mov-frag-encrypted
@@ -0,0 +1,57 @@
+#format: frame checksums
+#version: 2
+#hash: MD5
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 120x52
+#sar 0: 544/545
+#stream#, dts, pts, duration, size, hash
+0, 0, 0, 1, 9360, 920bdc277a6a31c1daed9aca44b10caf
+0, 1, 1, 1, 9360, f1c0b61fef593de57cb97be7fa846569
+0, 2, 2, 1, 9360, 6ef32d9d4398355aebf6d3fb11d51d3f
+0, 3, 3, 1, 9360, d38fd3ef1e5a92fc109b8dd9eb6dadeb
+0, 4, 4, 1, 9360, 54cc0c8a25d2f14f32663837d5e646f1
+0, 5, 5, 1, 9360, b4b6829726dc3decb8b80ba0c35bcf30
+0, 6, 6, 1, 9360, fca3f941e60a2f0a4ce30d5e0efbec3c
+0, 7, 7, 1, 9360, cda6e26b6c1039ff3d229b262c9210c3
+0, 8, 8, 1, 9360, f0d69255e3a27a8b4ae8a4b7b210929d
+0, 9, 9, 1, 9360, 12cb23dd4e32af9c3b35f943714e3fdd
+0, 10, 10, 1, 9360, 082aaf3216124ddcecb422fe5c832e82
+0, 11, 11, 1, 9360, ff37bb8cd6bd0412a3b3cb45db54afc9
+0, 12, 12, 1, 9360, dfb9085441575732844b6c2f05d5f542
+0, 13, 13, 1, 9360, 0017100feaaa9fc7eacd2447d50d7542
+0, 14, 14, 1, 9360, 4e2f1b8c4e04c59934c2f58541e62613
+0, 15, 15, 1, 9360, 27a44dfea7cd2d30e488194c34ab473c
+0, 16, 16, 1, 9360, fc7b56bd95e990a33cf575d1ef820902
+0, 17, 17, 1, 9360, fa2d1609e69714dffc410e65f3c8b755
+0, 18, 18, 1, 9360, 705d7429f447cb13febe202d567795f2
+0, 19, 19, 1, 9360, 234802ce86e868faaf2cd40a286846ea
+0, 20, 20, 1, 9360, 2f0354b40d211d0a4ade4568bea4f85e
+0, 21, 21, 1, 9360, e96af3b6c0cc931463ca77d6be0f1148
+0, 22, 22, 1, 9360, 04a904d798361959971361401879c7e4
+0, 23, 23, 1, 9360, 2f119642340df6d25362b5590ded46b7
+0, 24, 24, 1, 9360, 5993fca2e60050706f857ac76e48f386
+0, 25, 25, 1, 9360, 2ff3b5775fed3d527bfbbeea786787fe
+0, 26, 26, 1, 9360, 42024dbe23d3fb5b0d8987ae1ce390a8
+0, 27, 27, 1, 9360, d804204f0bd9db5f6a758e2c934d9e38
+0, 28, 28, 1, 9360, e322712e6e34c58ec1a2ab5e2c1e3bfe
+0, 29, 29, 1, 9360, 3975bd1a5f6a6b6260276777f9de611e
+0, 30, 30, 1, 9360, 4388f0412efc6310706a7cdedc859ea9
+0, 31, 31, 1, 9360, b4b9a11b0b86635267345a569640e8d4
+0, 32, 32, 1, 9360, 31879c7b8d6b67a4209ffde786bb8cb4
+0, 33, 33, 1, 9360, 4b6dc02d7c889fe4abd4e013b25f585a
+0, 34, 34, 1, 9360, dc73aae82bd39a1220d1106c8d3e8252
+0, 35, 35, 1, 9360, 54c7dfbd49f312806f6c1a89f7c2c36f
+0, 36, 36, 1, 9360, 150abc64f8994d444a521ea90570443c
+0, 37, 37, 1, 9360, d277cdc7dcadbe0016f2e950459e7ebf
+0, 38, 38, 1, 9360, 2196bf338ead90ea54687b85c73c8229
+0, 39, 39, 1, 9360, 53ce5da5365abc0bd3217dd98e7c465d
+0, 40, 40, 1, 9360, 34ee9832aea55c0c4e6f4381c413c10e
+0, 41, 41, 1, 9360, 1769c7b5849e4681119067a06ac29a4f
+0, 42, 42, 1, 9360, 71f53df739ef283a5184c91ef4b158e8
+0, 43, 43, 1, 9360, d2d394739e9a59c06f0354c16843cb63
+0, 44, 44, 1, 9360, d8e458e92ae29344505a24a3059fc584
+0, 45, 45, 1, 9360, 0f1b11a09911851b798df2ef76253a7f
+0, 46, 46, 1, 9360, 5c4a9f22baecf4e749c0d5c65a4f1007
+0, 47, 47, 1, 9360, 3e2b7e7262fdca08d9d1ef6070125c4b
diff --git a/tests/ref/fate/mov-tenc-only-encrypted b/tests/ref/fate/mov-tenc-only-encrypted
new file mode 100644
index 0000000000..1d57aa6a80
--- /dev/null
+++ b/tests/ref/fate/mov-tenc-only-encrypted
@@ -0,0 +1,57 @@
+#format: frame checksums
+#version: 2
+#hash: MD5
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 1024x436
+#sar 0: 1/1
+#stream#, dts, pts, duration, size, hash
+0, 0, 0, 1, 669696, f48f296a85eda5ba069dc851a3228bef
+0, 1, 1, 1, 669696, a50c5f69bfa3387d49b5bdf738e6529c
+0, 2, 2, 1, 669696, 05061299003760f6a4795b408f72aa31
+0, 3, 3, 1, 669696, 2572119f0b0cdd83f8a7e06252cecd3b
+0, 4, 4, 1, 669696, 29fe6a6bdb4a69018e318886a297f07e
+0, 5, 5, 1, 669696, e8233c7fbaecfbff965c7dfdd3982b1b
+0, 6, 6, 1, 669696, d9259df9880ff5d4a4b38282e67f407b
+0, 7, 7, 1, 669696, 3e8d795195038993503ea9ab6984c915
+0, 8, 8, 1, 669696, bc4e2d253b715a34f85aae1b080e3460
+0, 9, 9, 1, 669696, 09aba8b3a96f53f9268e7420a10bfab6
+0, 10, 10, 1, 669696, 179447977dd580da8b35fb5310a809ca
+0, 11, 11, 1, 669696, 7a0eea9d54577990345f5705ab9882be
+0, 12, 12, 1, 669696, 5bb96eb76f461825740e5938456df759
+0, 13, 13, 1, 669696, bd4ac4a760ead774b9422a27dc071964
+0, 14, 14, 1, 669696, 1cc05f760a9b751fc89e77f2bcc97259
+0, 15, 15, 1, 669696, 825d0dee6f0174ba7102892c7de30b4d
+0, 16, 16, 1, 669696, d26a2ef5267f6bb03c4e1d8514eee0df
+0, 17, 17, 1, 669696, c916ffdeadca76596a8f7fd47914b5ef
+0, 18, 18, 1, 669696, 6e085acfa7fee0658ea0ae6188274c17
+0, 19, 19, 1, 669696, 1e95fa5b3561283f05bf0bd44cb91721
+0, 20, 20, 1, 669696, 37e3d135aba9dfb8b87e441753115374
+0, 21, 21, 1, 669696, 9c398310e8564491de624393c16265ce
+0, 22, 22, 1, 669696, c87209e4d2617bc2ab40a75f455f09da
+0, 23, 23, 1, 669696, 2679c2f8d1d1af21982e245945c1ee60
+0, 24, 24, 1, 669696, 6151ab4781f31c5beb66b356ad547122
+0, 25, 25, 1, 669696, f7ef6293bfb3a6a329061cb6a5ed5a38
+0, 26, 26, 1, 669696, 2f6e666d14dfc407ca0c0f347b13eb08
+0, 27, 27, 1, 669696, 3454fa1730d79b1aa8dbbc865dc150f4
+0, 28, 28, 1, 669696, e93dc683e2453419a0419ab9af0f8f95
+0, 29, 29, 1, 669696, 031eb3154f7f83cf86d42bee66be9cf7
+0, 30, 30, 1, 669696, 1205c36723e88811206c68892d3aaed6
+0, 31, 31, 1, 669696, 7dd7a8a19dcd73b31ddc6a6d0c597a42
+0, 32, 32, 1, 669696, 7c91115368ea2531262a1197468bc3f4
+0, 33, 33, 1, 669696, 3cf6d9ba385e0fff76da33299ed5380c
+0, 34, 34, 1, 669696, 859fc8c3ef049e3c1175a85fb0a90a3d
+0, 35, 35, 1, 669696, 1d09ce6c7027103d99a4d5799f6e72ab
+0, 36, 36, 1, 669696, 3dcb8357408ac88abd734128d8f5dd6f
+0, 37, 37, 1, 669696, 4dafce137a0a5178f6efaec878e64d36
+0, 38, 38, 1, 669696, 44c478f29a1399ed03275a7357f57d48
+0, 39, 39, 1, 669696, 6e9edaac7414c0e14591ac3d4d0b1ac4
+0, 40, 40, 1, 669696, 522e4aaeea0825da27f631a9e690d654
+0, 41, 41, 1, 669696, 85f2502a718440834c40051d30f8a65e
+0, 42, 42, 1, 669696, ae8816f7bd4645ef1a17ee6d09b4c8d2
+0, 43, 43, 1, 669696, 914b006fa92f1eb3e590245749f6810d
+0, 44, 44, 1, 669696, 9406901542e94c429dff46108782ed69
+0, 45, 45, 1, 669696, 324c13641c39eef5c476023e358c0391
+0, 46, 46, 1, 669696, 4058e886e17c22e4eb9da1dd0d6ad891
+0, 47, 47, 1, 669696, 9edf9cd15eea985b42fd1f5035b1d693

[Jacob Trimble]

This doesn't support saio atoms with more than one offset.

Signed-off-by: Jacob Trimble <***@google.com>
---
libavformat/isom.h | 6 ++
libavformat/mov.c | 174 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 180 insertions(+)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 3794b1f0fd..3de8053da2 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -114,6 +114,12 @@ typedef struct MOVEncryptionIndex {
// settings will be used.
unsigned int nb_encrypted_samples;
AVEncryptionInfo **encrypted_samples;
+
+ uint8_t* auxiliary_info_sizes;
+ size_t auxiliary_info_sample_count;
+ uint8_t auxiliary_info_default_size;
+ size_t* auxiliary_offsets; ///< Absolute seek position
+ size_t auxiliary_offsets_count;
} MOVEncryptionIndex;

typedef struct MOVFragmentStreamInfo {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index eb3fb71e2a..554b2be8bd 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5835,6 +5835,165 @@ static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0;
}

+static int mov_parse_auxiliary_info(MOVContext *c, MOVStreamContext *sc, AVIOContext *pb, MOVEncryptionIndex *encryption_index)
+{
+ AVEncryptionInfo **sample;
+ int64_t prev_pos;
+ size_t sample_count, sample_info_size, i;
+ int ret = 0;
+
+ if (encryption_index->nb_encrypted_samples)
+ return 0;
+ sample_count = encryption_index->auxiliary_info_sample_count;
+ if (encryption_index->auxiliary_offsets_count != 1) {
+ av_log(c->fc, AV_LOG_ERROR, "Multiple auxiliary info chunks are not supported\n");
+ return AVERROR_PATCHWELCOME;
+ }
+
+ encryption_index->encrypted_samples = av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);
+ if (!encryption_index->encrypted_samples)
+ return AVERROR(ENOMEM);
+ encryption_index->nb_encrypted_samples = sample_count;
+
+ prev_pos = avio_tell(pb);
+ if (avio_seek(pb, encryption_index->auxiliary_offsets[0], SEEK_SET) != encryption_index->auxiliary_offsets[i]) {
+ av_log(c->fc, AV_LOG_INFO, "Failed to seek for auxiliary info, will only parse senc atoms for encryption info\n");
+ goto finish;
+ }
+
+ for (i = 0; i < sample_count; i++) {
+ sample = &encryption_index->encrypted_samples[i];
+ sample_info_size = encryption_index->auxiliary_info_default_size
+ ? encryption_index->auxiliary_info_default_size
+ : encryption_index->auxiliary_info_sizes[i];
+
+ ret = mov_read_sample_encryption_info(c, pb, sc, sample, sample_info_size > sc->cenc.per_sample_iv_size);
+ if (ret < 0)
+ goto finish;
+ }
+
+finish:
+ avio_seek(pb, prev_pos, SEEK_SET);
+ return ret;
+}
+
+static int mov_read_saiz(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+ MOVEncryptionIndex *encryption_index;
+ MOVStreamContext *sc;
+ int ret;
+ unsigned int sample_count;
+
+ ret = get_current_encryption_info(c, &encryption_index, &sc);
+ if (ret != 1)
+ return ret;
+
+ if (encryption_index->nb_encrypted_samples) {
+ // This can happen if we have both saio/saiz and senc atoms.
+ av_log(c->fc, AV_LOG_DEBUG, "ignoring duplicate encryption info in saiz\n");
+ return 0;
+ }
+
+ if (encryption_index->auxiliary_info_sample_count) {
+ av_log(c->fc, AV_LOG_ERROR, "duplicate saiz atom\n");
+ return AVERROR_INVALIDDATA;
+ }
+
+ avio_r8(pb); /* version */
+ if (avio_rb24(pb) & 0x01) { /* flags */
+ if (avio_rb32(pb) != sc->cenc.default_encrypted_sample->scheme) {
+ av_log(c->fc, AV_LOG_DEBUG, "ignoring saiz box with non-zero aux_info_type\n");
+ return 0;
+ }
+ if (avio_rb32(pb) != 0) {
+ av_log(c->fc, AV_LOG_DEBUG, "ignoring saiz box with non-zero aux_info_type_parameter\n");
+ return 0;
+ }
+ }
+
+ encryption_index->auxiliary_info_default_size = avio_r8(pb);
+ sample_count = avio_rb32(pb);
+ encryption_index->auxiliary_info_sample_count = sample_count;
+
+ if (encryption_index->auxiliary_info_default_size == 0) {
+ encryption_index->auxiliary_info_sizes = av_malloc(sample_count);
+ if (!encryption_index->auxiliary_info_sizes)
+ return AVERROR(ENOMEM);
+ if (avio_read(pb, encryption_index->auxiliary_info_sizes, sample_count) != sample_count) {
+ av_log(c->fc, AV_LOG_ERROR, "failed to read the auxiliary info\n");
+ return AVERROR_INVALIDDATA;
+ }
+ }
+
+ if (encryption_index->auxiliary_offsets_count) {
+ return mov_parse_auxiliary_info(c, sc, pb, encryption_index);
+ }
+
+ return 0;
+}
+
+static int mov_read_saio(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+ MOVEncryptionIndex *encryption_index;
+ MOVStreamContext *sc;
+ int i, ret;
+ unsigned int version, entry_count;
+
+ ret = get_current_encryption_info(c, &encryption_index, &sc);
+ if (ret != 1)
+ return ret;
+
+ if (encryption_index->nb_encrypted_samples) {
+ // This can happen if we have both saio/saiz and senc atoms.
+ av_log(c->fc, AV_LOG_DEBUG, "ignoring duplicate encryption info in saio\n");
+ return 0;
+ }
+
+ if (encryption_index->auxiliary_offsets_count) {
+ av_log(c->fc, AV_LOG_ERROR, "duplicate saio atom\n");
+ return AVERROR_INVALIDDATA;
+ }
+
+ version = avio_r8(pb); /* version */
+ if (avio_rb24(pb) & 0x01) { /* flags */
+ if (avio_rb32(pb) != sc->cenc.default_encrypted_sample->scheme) {
+ av_log(c->fc, AV_LOG_DEBUG, "ignoring saio box with non-zero aux_info_type\n");
+ return 0;
+ }
+ if (avio_rb32(pb) != 0) {
+ av_log(c->fc, AV_LOG_DEBUG, "ignoring saio box with non-zero aux_info_type_parameter\n");
+ return 0;
+ }
+ }
+
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);
+ if (!encryption_index->auxiliary_offsets)
+ return AVERROR(ENOMEM);
+ encryption_index->auxiliary_offsets_count = entry_count;
+
+ if (version == 0) {
+ for (i = 0; i < entry_count; i++) {
+ encryption_index->auxiliary_offsets[i] = avio_rb32(pb);
+ }
+ } else {
+ for (i = 0; i < entry_count; i++) {
+ encryption_index->auxiliary_offsets[i] = avio_rb64(pb);
+ }
+ }
+ if (c->frag_index.current >= 0) {
+ for (i = 0; i < entry_count; i++) {
+ encryption_index->auxiliary_offsets[i] += c->fragment.base_data_offset;
+ }
+ }
+
+ if (encryption_index->auxiliary_info_sample_count) {
+ return mov_parse_auxiliary_info(c, sc, pb, encryption_index);
+ }
+
+ return 0;
+}
+
static int mov_read_schm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
AVStream *st;
@@ -6050,6 +6209,17 @@ static int cenc_filter(MOVContext *mov, MOVStreamContext *sc, AVPacket *pkt, int
}

if (encryption_index) {
+ if (encryption_index->auxiliary_info_sample_count &&
+ !encryption_index->nb_encrypted_samples) {
+ av_log(mov->fc, AV_LOG_ERROR, "saiz atom found without saio\n");
+ return AVERROR_INVALIDDATA;
+ }
+ if (encryption_index->auxiliary_offsets_count &&
+ !encryption_index->nb_encrypted_samples) {
+ av_log(mov->fc, AV_LOG_ERROR, "saio atom found without saiz\n");
+ return AVERROR_INVALIDDATA;
+ }
+
if (!encryption_index->nb_encrypted_samples) {
// Full-sample encryption with default settings.
encrypted_sample = sc->cenc.default_encrypted_sample;
@@ -6194,6 +6364,8 @@ static const MOVParseTableEntry mov_default_parse_table[] = {
{ MKTAG('s','i','n','f'), mov_read_default },
{ MKTAG('f','r','m','a'), mov_read_frma },
{ MKTAG('s','e','n','c'), mov_read_senc },
+{ MKTAG('s','a','i','z'), mov_read_saiz },
+{ MKTAG('s','a','i','o'), mov_read_saio },
{ MKTAG('s','c','h','m'), mov_read_schm },
{ MKTAG('s','c','h','i'), mov_read_default },
{ MKTAG('t','e','n','c'), mov_read_tenc },
@@ -6589,6 +6761,8 @@ static void mov_free_encryption_index(MOVEncryptionIndex **index) {
av_encryption_info_free((*index)->encrypted_samples[i]);
}
av_freep(&(*index)->encrypted_samples);
+ av_freep(&(*index)->auxiliary_info_sizes);
+ av_freep(&(*index)->auxiliary_offsets);
av_freep(index);
}

[Carl Eugen Hoyos]

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)

But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Carl Eugen

[Jacob Trimble]

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)
But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.

Post by Carl Eugen Hoyos
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[James Almer]

Post by Jacob Trimble
diff --git a/libavformat/mov.c b/libavformat/mov.c
index eb3fb71e2a..9ff4a809b7 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5835,6 +5835,177 @@ static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0;
}
+static int mov_parse_auxiliary_info(MOVContext *c, MOVStreamContext *sc, AVIOContext *pb, MOVEncryptionIndex *encryption_index)
+{
+ AVEncryptionInfo **sample;
+ int64_t prev_pos;
+ size_t sample_count, sample_info_size, i;
+ int ret = 0;
+
+ if (encryption_index->nb_encrypted_samples)
+ return 0;
+ sample_count = encryption_index->auxiliary_info_sample_count;
+ if (encryption_index->auxiliary_offsets_count != 1) {
+ av_log(c->fc, AV_LOG_ERROR, "Multiple auxiliary info chunks are not supported\n");
+ return AVERROR_PATCHWELCOME;
+ }
+
+ encryption_index->encrypted_samples = av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);

Number of elements should be the first argument, and size of each
element the second argument.

[Carl Eugen Hoyos]

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)
But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.
+ entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 ? 4 : 8);
+ if (avio_rb32(pb) != entry_count) {
+ av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
+ return AVERROR_INVALIDDATA;
+ }
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);

Does this avoid a 1G allocation for a file of a few bytes?

Didn't you simply increase the number of needed bytes to change in a valid
mov file to behave maliciously from one to two?

Thank you, Carl Eugen

[Jacob Trimble]

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)
But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.
+ entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 ? 4 : 8);
+ if (avio_rb32(pb) != entry_count) {
+ av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
+ return AVERROR_INVALIDDATA;
+ }
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);

Does this avoid a 1G allocation for a file of a few bytes?
Didn't you simply increase the number of needed bytes to change in a valid
mov file to behave maliciously from one to two?

From what I can tell, the mov_read_default method (which is what reads
child atoms) will verify "atom.size" to fit inside the parent atom.
This means that for "atom.size" to be excessively large for the file
size, the input would need to be non-seekable (since I think the
top-level atom uses the file size) and all the atoms would need to
have invalid sizes. But technically I guess it is possible.

But this is basically malloc some number of bytes then read that many
bytes. The only alternative I can think of (in the face of
non-seekable inputs) is to try-read in chunks until we hit EOF or the
end of the expected size. This seems like a lot of extra work that is
not mirrored elsewhere. There are several cases where this isn't
explicitly checked.

Also, how does this attack work? If the number is way too big, well
get EOM and error out. If it is large but there is enough memory,
we'll hit EOF and error out. Would it be better to explicitly check
for EOF to avoid the loop running for longer than needed? Or how
about freeing the memory on error so we don't keep the useless memory
around on the error case (even though the app will probably just free
the context anyway).

Post by Carl Eugen Hoyos
Thank you, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Carl Eugen Hoyos]

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)
But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.
+ entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 ? 4 : 8);
+ if (avio_rb32(pb) != entry_count) {
+ av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
+ return AVERROR_INVALIDDATA;
+ }
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);

Does this avoid a 1G allocation for a file of a few bytes?
Didn't you simply increase the number of needed bytes to change in a valid
mov file to behave maliciously from one to two?

From what I can tell, the mov_read_default method (which is what reads
child atoms) will verify "atom.size" to fit inside the parent atom.
This means that for "atom.size" to be excessively large for the file
size, the input would need to be non-seekable (since I think the
top-level atom uses the file size) and all the atoms would need to
have invalid sizes.

(I did not check this but I am not convinced the sample I fixed last
week is so sophisticated.)

Post by Jacob Trimble
But technically I guess it is possible.

Thank you.

Post by Jacob Trimble
But this is basically malloc some number of bytes then read that many
bytes. The only alternative I can think of (in the face of
non-seekable inputs) is to try-read in chunks until we hit EOF or the
end of the expected size. This seems like a lot of extra work that is
not mirrored elsewhere.

On the contrary.

But you are right, I forgot to write that you have to add an "if (!eof)"
to the reading loops, see the function that above commit changed.

Post by Jacob Trimble
There are several cases where this isn't explicitly checked.

Yes, and they will be fixed, please don't add another one.

Post by Jacob Trimble
Also, how does this attack work? If the number is way too big, well
get EOM and error out.

Which not only causes dos but also makes checking for other (if you
like: more dangerous) issues more difficult which is bad. We already
know that there are cases where the issue is hard to avoid, I believe
this is not such a case.

It is possible to create (valid) samples that allocate a huge amount
of memory but very small files should not immediately allocate an
amount of several G.

Carl Eugen

[Jacob Trimble]

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)
But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.
+ entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 ? 4 : 8);
+ if (avio_rb32(pb) != entry_count) {
+ av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
+ return AVERROR_INVALIDDATA;
+ }
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);

Does this avoid a 1G allocation for a file of a few bytes?
Didn't you simply increase the number of needed bytes to change in a valid
mov file to behave maliciously from one to two?

From what I can tell, the mov_read_default method (which is what reads
child atoms) will verify "atom.size" to fit inside the parent atom.
This means that for "atom.size" to be excessively large for the file
size, the input would need to be non-seekable (since I think the
top-level atom uses the file size) and all the atoms would need to
have invalid sizes.

(I did not check this but I am not convinced the sample I fixed last
week is so sophisticated.)

Post by Jacob Trimble
But technically I guess it is possible.

Thank you.

Post by Jacob Trimble
But this is basically malloc some number of bytes then read that many
bytes. The only alternative I can think of (in the face of
non-seekable inputs) is to try-read in chunks until we hit EOF or the
end of the expected size. This seems like a lot of extra work that is
not mirrored elsewhere.

On the contrary.
But you are right, I forgot to write that you have to add an "if (!eof)"
to the reading loops, see the function that above commit changed.

Post by Jacob Trimble
There are several cases where this isn't explicitly checked.

Yes, and they will be fixed, please don't add another one.

Post by Jacob Trimble
Also, how does this attack work? If the number is way too big, well
get EOM and error out.

Which not only causes dos but also makes checking for other (if you
like: more dangerous) issues more difficult which is bad. We already
know that there are cases where the issue is hard to avoid, I believe
this is not such a case.
It is possible to create (valid) samples that allocate a huge amount
of memory but very small files should not immediately allocate an
amount of several G.

Done.

Post by Carl Eugen Hoyos
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Carl Eugen Hoyos]

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)
But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.
+ entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 ? 4 : 8);
+ if (avio_rb32(pb) != entry_count) {
+ av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
+ return AVERROR_INVALIDDATA;
+ }
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);

Does this avoid a 1G allocation for a file of a few bytes?
Didn't you simply increase the number of needed bytes to change in a valid
mov file to behave maliciously from one to two?

From what I can tell, the mov_read_default method (which is what reads
child atoms) will verify "atom.size" to fit inside the parent atom.
This means that for "atom.size" to be excessively large for the file
size, the input would need to be non-seekable (since I think the
top-level atom uses the file size) and all the atoms would need to
have invalid sizes.

(I did not check this but I am not convinced the sample I fixed last
week is so sophisticated.)

Post by Jacob Trimble
But technically I guess it is possible.

Thank you.

Post by Jacob Trimble
But this is basically malloc some number of bytes then read that many
bytes. The only alternative I can think of (in the face of
non-seekable inputs) is to try-read in chunks until we hit EOF or the
end of the expected size. This seems like a lot of extra work that is
not mirrored elsewhere.

On the contrary.
But you are right, I forgot to write that you have to add an "if (!eof)"
to the reading loops, see the function that above commit changed.

Post by Jacob Trimble
There are several cases where this isn't explicitly checked.

Yes, and they will be fixed, please don't add another one.

Post by Jacob Trimble
Also, how does this attack work? If the number is way too big, well
get EOM and error out.

Which not only causes dos but also makes checking for other (if you
like: more dangerous) issues more difficult which is bad. We already
know that there are cases where the issue is hard to avoid, I believe
this is not such a case.
It is possible to create (valid) samples that allocate a huge amount
of memory but very small files should not immediately allocate an
amount of several G.

Done.

+ entry_count = avio_rb32(pb);

This has to be checked for later overflow, same in other spots.

+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets),
entry_count);

I believe you forgot to remove these two lines.

Note that I chose "1024*1024" arbitrarily to avoid a speed-loss for
(most likely) all valid files when fixing the dos in 1112ba01.
I don't know what a good lower limit for your use-case can be, or
if only using av_fast_realloc() - without the high starting value -
makes sense.

Carl Eugen

[Jacob Trimble]

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)
But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.
+ entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 ? 4 : 8);
+ if (avio_rb32(pb) != entry_count) {
+ av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
+ return AVERROR_INVALIDDATA;
+ }
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);

Does this avoid a 1G allocation for a file of a few bytes?
Didn't you simply increase the number of needed bytes to change in a valid
mov file to behave maliciously from one to two?

From what I can tell, the mov_read_default method (which is what reads
child atoms) will verify "atom.size" to fit inside the parent atom.
This means that for "atom.size" to be excessively large for the file
size, the input would need to be non-seekable (since I think the
top-level atom uses the file size) and all the atoms would need to
have invalid sizes.

(I did not check this but I am not convinced the sample I fixed last
week is so sophisticated.)

Post by Jacob Trimble
But technically I guess it is possible.

Thank you.

Post by Jacob Trimble
But this is basically malloc some number of bytes then read that many
bytes. The only alternative I can think of (in the face of
non-seekable inputs) is to try-read in chunks until we hit EOF or the
end of the expected size. This seems like a lot of extra work that is
not mirrored elsewhere.

On the contrary.
But you are right, I forgot to write that you have to add an "if (!eof)"
to the reading loops, see the function that above commit changed.

Post by Jacob Trimble
There are several cases where this isn't explicitly checked.

Yes, and they will be fixed, please don't add another one.

Post by Jacob Trimble
Also, how does this attack work? If the number is way too big, well
get EOM and error out.

Which not only causes dos but also makes checking for other (if you
like: more dangerous) issues more difficult which is bad. We already
know that there are cases where the issue is hard to avoid, I believe
this is not such a case.
It is possible to create (valid) samples that allocate a huge amount
of memory but very small files should not immediately allocate an
amount of several G.

Done.

+ entry_count = avio_rb32(pb);
This has to be checked for later overflow, same in other spots.

Done

Post by Jacob Trimble
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);
I believe you forgot to remove these two lines.

Yep, done.

Post by Jacob Trimble
Note that I chose "1024*1024" arbitrarily to avoid a speed-loss for
(most likely) all valid files when fixing the dos in 1112ba01.
I don't know what a good lower limit for your use-case can be, or
if only using av_fast_realloc() - without the high starting value -
makes sense.

Ok, for the saio atoms, it will likely be small (changed it to 1024)
since it will either be the number of tenc atoms or the number of
chunks or 1. Later code actually only supports one offset, but I
didn't want to hard-code that requirement here.

Post by Jacob Trimble
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Michael Niedermayer]

Post by Jacob Trimble

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)
But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.
+ entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 ? 4 : 8);
+ if (avio_rb32(pb) != entry_count) {
+ av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
+ return AVERROR_INVALIDDATA;
+ }
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);

Does this avoid a 1G allocation for a file of a few bytes?
Didn't you simply increase the number of needed bytes to change in a valid
mov file to behave maliciously from one to two?

From what I can tell, the mov_read_default method (which is what reads
child atoms) will verify "atom.size" to fit inside the parent atom.
This means that for "atom.size" to be excessively large for the file
size, the input would need to be non-seekable (since I think the
top-level atom uses the file size) and all the atoms would need to
have invalid sizes.

(I did not check this but I am not convinced the sample I fixed last
week is so sophisticated.)

Post by Jacob Trimble
But technically I guess it is possible.

Thank you.

Post by Jacob Trimble
But this is basically malloc some number of bytes then read that many
bytes. The only alternative I can think of (in the face of
non-seekable inputs) is to try-read in chunks until we hit EOF or the
end of the expected size. This seems like a lot of extra work that is
not mirrored elsewhere.

On the contrary.
But you are right, I forgot to write that you have to add an "if (!eof)"
to the reading loops, see the function that above commit changed.

Post by Jacob Trimble
There are several cases where this isn't explicitly checked.

Yes, and they will be fixed, please don't add another one.

Post by Jacob Trimble
Also, how does this attack work? If the number is way too big, well
get EOM and error out.

Which not only causes dos but also makes checking for other (if you
like: more dangerous) issues more difficult which is bad. We already
know that there are cases where the issue is hard to avoid, I believe
this is not such a case.
It is possible to create (valid) samples that allocate a huge amount
of memory but very small files should not immediately allocate an
amount of several G.

Done.

+ entry_count = avio_rb32(pb);
This has to be checked for later overflow, same in other spots.

Done

Post by Jacob Trimble
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);
I believe you forgot to remove these two lines.

Yep, done.

Post by Jacob Trimble
Note that I chose "1024*1024" arbitrarily to avoid a speed-loss for
(most likely) all valid files when fixing the dos in 1112ba01.
I don't know what a good lower limit for your use-case can be, or
if only using av_fast_realloc() - without the high starting value -
makes sense.

Ok, for the saio atoms, it will likely be small (changed it to 1024)
since it will either be the number of tenc atoms or the number of
chunks or 1. Later code actually only supports one offset, but I
didn't want to hard-code that requirement here.

Post by Jacob Trimble
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

isom.h | 6 +
mov.c | 237 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 243 insertions(+)
0c952e937ee35e8f95d1183047dd8d4f4bb1a7a2 0002-avformat-mov-Fix-parsing-of-saio-v4.patch
From 76c6870513481c14c5c134f1b8e7e9a91e17e6b5 Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted
content.
This doesn't support saio atoms with more than one offset.

Seems not to apply:

Applying: avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.
error: sha1 information is lacking or useless (libavformat/isom.h).
error: could not build fake ancestor
Patch failed at 0001 avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[...]

thanks

[Jacob Trimble]

On Thu, Apr 19, 2018 at 2:07 AM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)
But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.
+ entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 ? 4 : 8);
+ if (avio_rb32(pb) != entry_count) {
+ av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
+ return AVERROR_INVALIDDATA;
+ }
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);

Does this avoid a 1G allocation for a file of a few bytes?
Didn't you simply increase the number of needed bytes to change in a valid
mov file to behave maliciously from one to two?

From what I can tell, the mov_read_default method (which is what reads
child atoms) will verify "atom.size" to fit inside the parent atom.
This means that for "atom.size" to be excessively large for the file
size, the input would need to be non-seekable (since I think the
top-level atom uses the file size) and all the atoms would need to
have invalid sizes.

(I did not check this but I am not convinced the sample I fixed last
week is so sophisticated.)

Post by Jacob Trimble
But technically I guess it is possible.

Thank you.

Post by Jacob Trimble
But this is basically malloc some number of bytes then read that many
bytes. The only alternative I can think of (in the face of
non-seekable inputs) is to try-read in chunks until we hit EOF or the
end of the expected size. This seems like a lot of extra work that is
not mirrored elsewhere.

On the contrary.
But you are right, I forgot to write that you have to add an "if (!eof)"
to the reading loops, see the function that above commit changed.

Post by Jacob Trimble
There are several cases where this isn't explicitly checked.

Yes, and they will be fixed, please don't add another one.

Post by Jacob Trimble
Also, how does this attack work? If the number is way too big, well
get EOM and error out.

Which not only causes dos but also makes checking for other (if you
like: more dangerous) issues more difficult which is bad. We already
know that there are cases where the issue is hard to avoid, I believe
this is not such a case.
It is possible to create (valid) samples that allocate a huge amount
of memory but very small files should not immediately allocate an
amount of several G.

Done.

+ entry_count = avio_rb32(pb);
This has to be checked for later overflow, same in other spots.

Done

Post by Jacob Trimble
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);
I believe you forgot to remove these two lines.

Yep, done.

Post by Jacob Trimble
Note that I chose "1024*1024" arbitrarily to avoid a speed-loss for
(most likely) all valid files when fixing the dos in 1112ba01.
I don't know what a good lower limit for your use-case can be, or
if only using av_fast_realloc() - without the high starting value -
makes sense.

Ok, for the saio atoms, it will likely be small (changed it to 1024)
since it will either be the number of tenc atoms or the number of
chunks or 1. Later code actually only supports one offset, but I
didn't want to hard-code that requirement here.

Post by Jacob Trimble
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

isom.h | 6 +
mov.c | 237 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 243 insertions(+)
0c952e937ee35e8f95d1183047dd8d4f4bb1a7a2 0002-avformat-mov-Fix-parsing-of-saio-v4.patch
From 76c6870513481c14c5c134f1b8e7e9a91e17e6b5 Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted
content.
This doesn't support saio atoms with more than one offset.

Applying: avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.
error: sha1 information is lacking or useless (libavformat/isom.h).
error: could not build fake ancestor
Patch failed at 0001 avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

I have never used |git am| before, but I am able to apply it fine using patch:

patch -i 0002*.patch -p1 --no-backup-if-mismatch

Maybe you tried to apply without the "remove old encryption info
methods" patch (which was part of the previous email)? I can apply it
against the current master just fine. Here is a version against the
latest master in case there was some hash problems.

Post by Michael Niedermayer
[...]
thanks
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Michael Niedermayer]

Post by Jacob Trimble
On Thu, Apr 19, 2018 at 2:07 AM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ entry_count = avio_rb32(pb);
+ encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), entry_count);

(sizeof(variable) instead of sizeof(type), please.)
But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.
+ entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 ? 4 : 8);
+ if (avio_rb32(pb) != entry_count) {
+ av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
+ return AVERROR_INVALIDDATA;
+ }
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), entry_count);

Does this avoid a 1G allocation for a file of a few bytes?
Didn't you simply increase the number of needed bytes to change in a valid
mov file to behave maliciously from one to two?

From what I can tell, the mov_read_default method (which is what reads
child atoms) will verify "atom.size" to fit inside the parent atom.
This means that for "atom.size" to be excessively large for the file
size, the input would need to be non-seekable (since I think the
top-level atom uses the file size) and all the atoms would need to
have invalid sizes.

(I did not check this but I am not convinced the sample I fixed last
week is so sophisticated.)

Post by Jacob Trimble
But technically I guess it is possible.

Thank you.

Post by Jacob Trimble
But this is basically malloc some number of bytes then read that many
bytes. The only alternative I can think of (in the face of
non-seekable inputs) is to try-read in chunks until we hit EOF or the
end of the expected size. This seems like a lot of extra work that is
not mirrored elsewhere.

On the contrary.
But you are right, I forgot to write that you have to add an "if (!eof)"
to the reading loops, see the function that above commit changed.

Post by Jacob Trimble
There are several cases where this isn't explicitly checked.

Yes, and they will be fixed, please don't add another one.

Post by Jacob Trimble
Also, how does this attack work? If the number is way too big, well
get EOM and error out.

Which not only causes dos but also makes checking for other (if you
like: more dangerous) issues more difficult which is bad. We already
know that there are cases where the issue is hard to avoid, I believe
this is not such a case.
It is possible to create (valid) samples that allocate a huge amount
of memory but very small files should not immediately allocate an
amount of several G.

Done.

+ entry_count = avio_rb32(pb);
This has to be checked for later overflow, same in other spots.

Done

Post by Jacob Trimble
+ encryption_index->auxiliary_offsets =
+ av_malloc_array(sizeof(*encryption_index->auxiliary_offsets),
entry_count);
I believe you forgot to remove these two lines.

Yep, done.

Post by Jacob Trimble
Note that I chose "1024*1024" arbitrarily to avoid a speed-loss for
(most likely) all valid files when fixing the dos in 1112ba01.
I don't know what a good lower limit for your use-case can be, or
if only using av_fast_realloc() - without the high starting value -
makes sense.

Ok, for the saio atoms, it will likely be small (changed it to 1024)
since it will either be the number of tenc atoms or the number of
chunks or 1. Later code actually only supports one offset, but I
didn't want to hard-code that requirement here.

Post by Jacob Trimble
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

isom.h | 6 +
mov.c | 237 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 243 insertions(+)
0c952e937ee35e8f95d1183047dd8d4f4bb1a7a2 0002-avformat-mov-Fix-parsing-of-saio-v4.patch
From 76c6870513481c14c5c134f1b8e7e9a91e17e6b5 Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted
content.
This doesn't support saio atoms with more than one offset.

Applying: avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.
error: sha1 information is lacking or useless (libavformat/isom.h).
error: could not build fake ancestor
Patch failed at 0001 avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

patch -i 0002*.patch -p1 --no-backup-if-mismatch
Maybe you tried to apply without the "remove old encryption info
methods" patch (which was part of the previous email)? I can apply it
against the current master just fine. Here is a version against the
latest master in case there was some hash problems.

yes, that applies

will apply

thx

[...]

[Jacob Trimble]

This exposes encryption info from the container to the app. This
includes key ID, IV, and subsample byte ranges. The info is passed
using the new side-data AV_PKT_DATA_ENCRYPTION_INIT_DATA.

Signed-off-by: Jacob Trimble <***@google.com>
---
libavformat/mov.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 554b2be8bd..abd59d8c7b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5994,6 +5994,32 @@ static int mov_read_saio(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0;
}

+static int mov_read_pssh(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+ AVStream *st;
+ uint8_t* side_data;
+ size_t size;
+
+ if (c->fc->nb_streams < 1)
+ return 0;
+ st = c->fc->streams[c->fc->nb_streams-1];
+
+ size = atom.size + 8;
+ side_data = av_stream_new_side_data(st, AV_PKT_DATA_ENCRYPTION_INIT_DATA, size);
+ if (!side_data) {
+ return AVERROR(ENOMEM);
+ }
+
+ AV_WB32(side_data, size);
+ AV_WL32(side_data + 4, MKTAG('p','s','s','h'));
+ if (avio_read(pb, side_data + 8, atom.size) != atom.size) {
+ av_log(c->fc, AV_LOG_ERROR, "failed to read the pssh atom\n");
+ return AVERROR_INVALIDDATA;
+ }
+
+ return 0;
+}
+
static int mov_read_schm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
AVStream *st;
@@ -6233,6 +6259,8 @@ static int cenc_filter(MOVContext *mov, MOVStreamContext *sc, AVPacket *pkt, int

if (mov->decryption_key) {
return cenc_decrypt(mov, sc, encrypted_sample, pkt->data, pkt->size);
+ } else {
+ return av_encryption_info_add_side_data(pkt, encrypted_sample);
}
}

@@ -6366,6 +6394,7 @@ static const MOVParseTableEntry mov_default_parse_table[] = {
{ MKTAG('s','e','n','c'), mov_read_senc },
{ MKTAG('s','a','i','z'), mov_read_saiz },
{ MKTAG('s','a','i','o'), mov_read_saio },
+{ MKTAG('p','s','s','h'), mov_read_pssh },
{ MKTAG('s','c','h','m'), mov_read_schm },
{ MKTAG('s','c','h','i'), mov_read_default },
{ MKTAG('t','e','n','c'), mov_read_tenc },

[Carl Eugen Hoyos]

Post by Jacob Trimble
+ AV_WB32(side_data, size);
+ AV_WL32(side_data + 4, MKTAG('p','s','s','h'));

I didn't check:
Is this what applications on both big- and little-endian expect?

Carl Eugen

[Jacob Trimble]

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ AV_WB32(side_data, size);
+ AV_WL32(side_data + 4, MKTAG('p','s','s','h'));

Is this what applications on both big- and little-endian expect?

Yes. This should match the MP4 atom, so the size and 'pssh' string
should be big-endian.

Post by Carl Eugen Hoyos
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Jacob Trimble]

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ AV_WB32(side_data, size);
+ AV_WL32(side_data + 4, MKTAG('p','s','s','h'));

Is this what applications on both big- and little-endian expect?

Yes. This should match the MP4 atom, so the size and 'pssh' string
should be big-endian.

Post by Carl Eugen Hoyos
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Updated with the new design for the side data and applied the realloc
fix to avoid large allocations.

[Carl Eugen Hoyos]

Post by Jacob Trimble
Updated with the new design for the side data and applied the realloc
fix to avoid large allocations.
+ kid_count = avio_rb32(pb);

Missing check here ...

Post by Jacob Trimble
+ for (; i < kid_count && !pb->eof_reached; i++) {
+ unsigned int min_kid_count = FFMIN(FFMAX(i, 1024), kid_count);
+ key_ids = av_fast_realloc(info->key_ids, &alloc_size,
+ min_kid_count * sizeof(*key_ids));

... for an overflow here.

Thank you, Carl Eugen

[Jacob Trimble]

Post by Carl Eugen Hoyos

Post by Jacob Trimble
Updated with the new design for the side data and applied the realloc
fix to avoid large allocations.
+ kid_count = avio_rb32(pb);

Missing check here ...

Post by Jacob Trimble
+ for (; i < kid_count && !pb->eof_reached; i++) {
+ unsigned int min_kid_count = FFMIN(FFMAX(i, 1024), kid_count);
+ key_ids = av_fast_realloc(info->key_ids, &alloc_size,
+ min_kid_count * sizeof(*key_ids));

... for an overflow here.

Done

Post by Carl Eugen Hoyos
Thank you, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Jacob Trimble]

Rebased and updated to handle multiple PSSH atoms. PTAL.

Post by Jacob Trimble

2018-01-09 0:22 GMT+01:00 Jacob Trimble <

Post by Jacob Trimble
Updated with the new design for the side data and applied the realloc
fix to avoid large allocations.
+ kid_count = avio_rb32(pb);

Missing check here ...

Post by Jacob Trimble
+ for (; i < kid_count && !pb->eof_reached; i++) {
+ unsigned int min_kid_count = FFMIN(FFMAX(i, 1024),

kid_count);

Post by Jacob Trimble
+ key_ids = av_fast_realloc(info->key_ids, &alloc_size,
+ min_kid_count *

sizeof(*key_ids));

... for an overflow here.

Done

Thank you, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Jacob Trimble]

Post by Jacob Trimble
Rebased and updated to handle multiple PSSH atoms. PTAL.

Post by Carl Eugen Hoyos

Post by Jacob Trimble
Updated with the new design for the side data and applied the realloc
fix to avoid large allocations.
+ kid_count = avio_rb32(pb);

Missing check here ...

Post by Jacob Trimble
+ for (; i < kid_count && !pb->eof_reached; i++) {
+ unsigned int min_kid_count = FFMIN(FFMAX(i, 1024), kid_count);
+ key_ids = av_fast_realloc(info->key_ids, &alloc_size,
+ min_kid_count * sizeof(*key_ids));

... for an overflow here.

Done

Post by Carl Eugen Hoyos
Thank you, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Ping.

[Michael Niedermayer]

Post by Jacob Trimble
Rebased and updated to handle multiple PSSH atoms. PTAL.

Post by Carl Eugen Hoyos

Post by Jacob Trimble
Updated with the new design for the side data and applied the realloc
fix to avoid large allocations.
+ kid_count = avio_rb32(pb);

Missing check here ...

Post by Jacob Trimble
+ for (; i < kid_count && !pb->eof_reached; i++) {
+ unsigned int min_kid_count = FFMIN(FFMAX(i, 1024), kid_count);
+ key_ids = av_fast_realloc(info->key_ids, &alloc_size,
+ min_kid_count * sizeof(*key_ids));

... for an overflow here.

Done

Post by Carl Eugen Hoyos
Thank you, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Ping.

will apply

[...]

[Jacob Trimble]

[...]

This adds two new fate tests that need to be uploaded by someone:

https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-frag-encrypted.mp4
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-tenc-only-encrypted.mp4

[James Almer]

Post by Jacob Trimble
diff --git a/libavutil/aes_ctr.c b/libavutil/aes_ctr.c
index e9c568fe0d..6ed69c8e10 100644
--- a/libavutil/aes_ctr.c
+++ b/libavutil/aes_ctr.c
@@ -38,10 +38,9 @@ struct AVAESCTR *av_aes_ctr_alloc(void)
return av_mallocz(sizeof(struct AVAESCTR));
}
-void av_aes_ctr_set_iv(struct AVAESCTR *a, const uint8_t* iv)
+void av_aes_ctr_set_full_iv(struct AVAESCTR *a, const uint8_t* iv)
{
- memcpy(a->counter, iv, AES_CTR_IV_SIZE);
- memset(a->counter + AES_CTR_IV_SIZE, 0, sizeof(a->counter) - AES_CTR_IV_SIZE);
+ memcpy(a->counter, iv, sizeof(a->counter));
a->block_offset = 0;
}
@@ -52,12 +51,14 @@ const uint8_t* av_aes_ctr_get_iv(struct AVAESCTR *a)
void av_aes_ctr_set_random_iv(struct AVAESCTR *a)
{
- uint32_t iv[2];
+ uint32_t iv[4];
iv[0] = av_get_random_seed();
iv[1] = av_get_random_seed();
+ iv[2] = 0;
+ iv[3] = 0;
- av_aes_ctr_set_iv(a, (uint8_t*)iv);
+ av_aes_ctr_set_full_iv(a, (uint8_t*)iv);
}
int av_aes_ctr_init(struct AVAESCTR *a, const uint8_t *key)
diff --git a/libavutil/aes_ctr.h b/libavutil/aes_ctr.h
index f596fa6a46..5995b37bec 100644
--- a/libavutil/aes_ctr.h
+++ b/libavutil/aes_ctr.h
@@ -67,9 +67,9 @@ const uint8_t* av_aes_ctr_get_iv(struct AVAESCTR *a);
void av_aes_ctr_set_random_iv(struct AVAESCTR *a);
/**
- * Forcefully change the iv
+ * Forcefully change the "full" 16-byte iv, including the counter
*/
-void av_aes_ctr_set_iv(struct AVAESCTR *a, const uint8_t* iv);
+void av_aes_ctr_set_full_iv(struct AVAESCTR *a, const uint8_t* iv);
/**
* Increment the top 64 bit of the iv (performed after each frame)

You can't remove API just like that without a deprecation period.
Add a new av_aes_ctr_set_full_iv() function, and either leave
av_aes_ctr_set_iv() alone or deprecate it if it effectively becomes
superfluous after adding the new function.

Also, this patch needs to be split in three. One for the aes_crt
changes, one for the encryption_info changes, and one for mov changes,
with a minor libavutil version bump for the former two, and the
corresponding APIChanges entry.
Alternatively, you could also squash the new encryption_info API from
this patch into the one that actually introduces the entire feature.

[Carl Eugen Hoyos]

Post by Jacob Trimble
+ if (!frag_stream_info->encryption_index) {
+ frag_stream_info->encryption_index = av_mallocz(sizeof(MOVEncryptionIndex));

sizeof(variable), please.

[...]

Post by Jacob Trimble
+ sample_count = avio_rb32(pb);
+
+ encryption_index->encrypted_samples = av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);

This should be avoided if possible, see below.

Post by Jacob Trimble
+ if (!encryption_index->encrypted_samples) {
return AVERROR(ENOMEM);
}
+ encryption_index->nb_encrypted_samples = sample_count;
- return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
+ for (i = 0; i < sample_count; i++) {

Please check here for eof...

Post by Jacob Trimble
+ ret = mov_read_sample_encryption_info(c, pb, sc, &encryption_index->encrypted_samples[i], use_subsamples);

... and insert a realloc here to avoid the large allocation above, see 1112ba01.

Thank you, Carl Eugen

[Jacob Trimble]

Post by James Almer
You can't remove API just like that without a deprecation period.
Add a new av_aes_ctr_set_full_iv() function, and either leave
av_aes_ctr_set_iv() alone or deprecate it if it effectively becomes
superfluous after adding the new function.
Also, this patch needs to be split in three. One for the aes_crt
changes, one for the encryption_info changes, and one for mov changes,
with a minor libavutil version bump for the former two, and the
corresponding APIChanges entry.
Alternatively, you could also squash the new encryption_info API from
this patch into the one that actually introduces the entire feature.

Whoops, I thought that was internal-only. Done and split into its own change.

Post by James Almer

Post by Jacob Trimble
+ if (!frag_stream_info->encryption_index) {
+ frag_stream_info->encryption_index = av_mallocz(sizeof(MOVEncryptionIndex));

sizeof(variable), please.
[...]

Post by Jacob Trimble
+ sample_count = avio_rb32(pb);
+
+ encryption_index->encrypted_samples = av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);

This should be avoided if possible, see below.

Post by Jacob Trimble
+ if (!encryption_index->encrypted_samples) {
return AVERROR(ENOMEM);
}
+ encryption_index->nb_encrypted_samples = sample_count;
- return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
+ for (i = 0; i < sample_count; i++) {

Please check here for eof...

Post by Jacob Trimble
+ ret = mov_read_sample_encryption_info(c, pb, sc, &encryption_index->encrypted_samples[i], use_subsamples);

... and insert a realloc here to avoid the large allocation above, see 1112ba01.

Done.

Post by James Almer
Thank you, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Carl Eugen Hoyos]

Post by Jacob Trimble

Post by James Almer
You can't remove API just like that without a deprecation period.
Add a new av_aes_ctr_set_full_iv() function, and either leave
av_aes_ctr_set_iv() alone or deprecate it if it effectively becomes
superfluous after adding the new function.
Also, this patch needs to be split in three. One for the aes_crt
changes, one for the encryption_info changes, and one for mov changes,
with a minor libavutil version bump for the former two, and the
corresponding APIChanges entry.
Alternatively, you could also squash the new encryption_info API from
this patch into the one that actually introduces the entire feature.

Whoops, I thought that was internal-only. Done and split into its own change.

Post by James Almer

Post by Jacob Trimble
+ if (!frag_stream_info->encryption_index) {
+ frag_stream_info->encryption_index = av_mallocz(sizeof(MOVEncryptionIndex));

sizeof(variable), please.

Do you disagree?
I have no strong opinion, but I thought it makes the code more robust...

Post by Jacob Trimble

Post by James Almer
[...]

Post by Jacob Trimble
+ sample_count = avio_rb32(pb);
+
+ encryption_index->encrypted_samples =
av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);

This should be avoided if possible, see below.

Post by Jacob Trimble
+ if (!encryption_index->encrypted_samples) {
return AVERROR(ENOMEM);
}
+ encryption_index->nb_encrypted_samples = sample_count;
- return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
+ for (i = 0; i < sample_count; i++) {

Please check here for eof...

Post by Jacob Trimble
+ ret = mov_read_sample_encryption_info(c, pb, sc,
&encryption_index->encrypted_samples[i], use_subsamples);

... and insert a realloc here to avoid the large allocation above, see 1112ba01.

Done.
+ if (use_subsamples) {
+ subsample_count = avio_rb16(pb);
+ for (i = 0; i < subsample_count && !pb->eof_reached; i++) {
+ unsigned int min_subsamples = FFMIN(FFMAX(i, 1024 * 1024), subsample_count);
+ subsamples = av_fast_realloc((*sample)->subsamples, &alloc_size,
+ min_subsamples * sizeof(*subsamples));

The reason I did not comment on this block in the last mail is that
iiuc, the maximum allocation here is INT16_MAX * 8 which seems
acceptable (and there cannot be a realloc with the chosen initial
limit).

Post by Jacob Trimble
+ sample_count = avio_rb32(pb);

You have to check here...

+ for (i = 0; i < sample_count && !pb->eof_reached; i++) {
+ unsigned int min_samples = FFMIN(FFMAX(i, 1024 * 1024), sample_count);
+ encrypted_samples =
av_fast_realloc(encryption_index->encrypted_samples, &alloc_size,

+ min_samples *
sizeof(*encrypted_samples));

... if this product could overflow for the final reallocation, see 1112ba01.

Thank you, Carl Eugen

[Jacob Trimble]

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by James Almer
You can't remove API just like that without a deprecation period.
Add a new av_aes_ctr_set_full_iv() function, and either leave
av_aes_ctr_set_iv() alone or deprecate it if it effectively becomes
superfluous after adding the new function.
Also, this patch needs to be split in three. One for the aes_crt
changes, one for the encryption_info changes, and one for mov changes,
with a minor libavutil version bump for the former two, and the
corresponding APIChanges entry.
Alternatively, you could also squash the new encryption_info API from
this patch into the one that actually introduces the entire feature.

Whoops, I thought that was internal-only. Done and split into its own change.

Post by James Almer

Post by Jacob Trimble
+ if (!frag_stream_info->encryption_index) {
+ frag_stream_info->encryption_index = av_mallocz(sizeof(MOVEncryptionIndex));

sizeof(variable), please.

Do you disagree?
I have no strong opinion, but I thought it makes the code more robust...

I did it most other places, but forgot it here. Done.

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by James Almer
[...]

Post by Jacob Trimble
+ sample_count = avio_rb32(pb);
+
+ encryption_index->encrypted_samples =
av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);

This should be avoided if possible, see below.

Post by Jacob Trimble
+ if (!encryption_index->encrypted_samples) {
return AVERROR(ENOMEM);
}
+ encryption_index->nb_encrypted_samples = sample_count;
- return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
+ for (i = 0; i < sample_count; i++) {

Please check here for eof...

Post by Jacob Trimble
+ ret = mov_read_sample_encryption_info(c, pb, sc,
&encryption_index->encrypted_samples[i], use_subsamples);

... and insert a realloc here to avoid the large allocation above, see 1112ba01.

Done.
+ if (use_subsamples) {
+ subsample_count = avio_rb16(pb);
+ for (i = 0; i < subsample_count && !pb->eof_reached; i++) {
+ unsigned int min_subsamples = FFMIN(FFMAX(i, 1024 * 1024), subsample_count);
+ subsamples = av_fast_realloc((*sample)->subsamples, &alloc_size,
+ min_subsamples * sizeof(*subsamples));

The reason I did not comment on this block in the last mail is that
iiuc, the maximum allocation here is INT16_MAX * 8 which seems
acceptable (and there cannot be a realloc with the chosen initial
limit).

Ok, changed back.

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ sample_count = avio_rb32(pb);

You have to check here...
+ for (i = 0; i < sample_count && !pb->eof_reached; i++) {
+ unsigned int min_samples = FFMIN(FFMAX(i, 1024 * 1024), sample_count);
+ encrypted_samples =
av_fast_realloc(encryption_index->encrypted_samples, &alloc_size,
+ min_samples *
sizeof(*encrypted_samples));
... if this product could overflow for the final reallocation, see 1112ba01.

Done

Post by Carl Eugen Hoyos
Thank you, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Michael Niedermayer]

Post by Jacob Trimble

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by James Almer
You can't remove API just like that without a deprecation period.
Add a new av_aes_ctr_set_full_iv() function, and either leave
av_aes_ctr_set_iv() alone or deprecate it if it effectively becomes
superfluous after adding the new function.
Also, this patch needs to be split in three. One for the aes_crt
changes, one for the encryption_info changes, and one for mov changes,
with a minor libavutil version bump for the former two, and the
corresponding APIChanges entry.
Alternatively, you could also squash the new encryption_info API from
this patch into the one that actually introduces the entire feature.

Whoops, I thought that was internal-only. Done and split into its own change.

Post by James Almer

Post by Jacob Trimble
+ if (!frag_stream_info->encryption_index) {
+ frag_stream_info->encryption_index = av_mallocz(sizeof(MOVEncryptionIndex));

sizeof(variable), please.

Do you disagree?
I have no strong opinion, but I thought it makes the code more robust...

I did it most other places, but forgot it here. Done.

Post by Carl Eugen Hoyos

Post by Jacob Trimble

Post by James Almer
[...]

Post by Jacob Trimble
+ sample_count = avio_rb32(pb);
+
+ encryption_index->encrypted_samples =
av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);

This should be avoided if possible, see below.

Post by Jacob Trimble
+ if (!encryption_index->encrypted_samples) {
return AVERROR(ENOMEM);
}
+ encryption_index->nb_encrypted_samples = sample_count;
- return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
+ for (i = 0; i < sample_count; i++) {

Please check here for eof...

Post by Jacob Trimble
+ ret = mov_read_sample_encryption_info(c, pb, sc,
&encryption_index->encrypted_samples[i], use_subsamples);

... and insert a realloc here to avoid the large allocation above, see 1112ba01.

Done.
+ if (use_subsamples) {
+ subsample_count = avio_rb16(pb);
+ for (i = 0; i < subsample_count && !pb->eof_reached; i++) {
+ unsigned int min_subsamples = FFMIN(FFMAX(i, 1024 * 1024), subsample_count);
+ subsamples = av_fast_realloc((*sample)->subsamples, &alloc_size,
+ min_subsamples * sizeof(*subsamples));

The reason I did not comment on this block in the last mail is that
iiuc, the maximum allocation here is INT16_MAX * 8 which seems
acceptable (and there cannot be a realloc with the chosen initial
limit).

Ok, changed back.

Post by Carl Eugen Hoyos

Post by Jacob Trimble
+ sample_count = avio_rb32(pb);

You have to check here...
+ for (i = 0; i < sample_count && !pb->eof_reached; i++) {
+ unsigned int min_samples = FFMIN(FFMAX(i, 1024 * 1024), sample_count);
+ encrypted_samples =
av_fast_realloc(encryption_index->encrypted_samples, &alloc_size,
+ min_samples *
sizeof(*encrypted_samples));
... if this product could overflow for the final reallocation, see 1112ba01.

Done

Post by Carl Eugen Hoyos
Thank you, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

libavformat/isom.h | 20 -
libavformat/mov.c | 432 ++++++++++++++++++++++-----------
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
5 files changed, 422 insertions(+), 152 deletions(-)
21ec6d9850961f491553278e64042530cecaacbe 0001-avformat-mov-Increase-support-for-v3.patch
From e8261628e11347a8aa1b61de04c53cc1174cdae3 Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH 1/3] avformat/mov: Increase support for common encryption.

This causes a crash:

=================================================================
==4012==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eb78 at pc 0x000000a944aa bp 0x7ffcd481ce70 sp 0x7ffcd481ce68
READ of size 8 at 0x60200000eb78 thread T0
#0 0xa944a9 in mov_free_encryption_index ffmpeg/libavformat/mov.c:6615:20
#1 0xa6fb2b in mov_read_close ffmpeg/libavformat/mov.c:6693:13
#2 0xa6d96f in mov_read_header ffmpeg/libavformat/mov.c:6867:13
#3 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
#4 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1069:11
#5 0x4da0e7 in open_files ffmpeg/fftools/ffmpeg_opt.c:3202:15
#6 0x4d9d98 in ffmpeg_parse_options ffmpeg/fftools/ffmpeg_opt.c:3242:11
#7 0x50e98c in main ffmpeg/fftools/ffmpeg.c:4813:11
#8 0x7f9cf833cf44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287
#9 0x420da5 in _start (ffmpeg/ffmpeg_g+0x420da5)

0x60200000eb78 is located 4 bytes to the right of 4-byte region [0x60200000eb70,0x60200000eb74)
allocated by thread T0 here:
#0 0x4b126e in realloc (ffmpeg/ffmpeg_g+0x4b126e)
#1 0x218bbfe in av_strdup ffmpeg/libavutil/mem.c:256:15
#2 0x215eec1 in av_dict_set ffmpeg/libavutil/dict.c:87:22
#3 0x215f6e2 in av_dict_set_int ffmpeg/libavutil/dict.c:153:12
#4 0xa7644c in mov_read_ftyp ffmpeg/libavformat/mov.c:1109:5
#5 0xa6b153 in mov_read_default ffmpeg/libavformat/mov.c:6327:23
#6 0xa6c543 in mov_read_header ffmpeg/libavformat/mov.c:6865:20
#7 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
#8 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1069:11
#9 0x4da0e7 in open_files ffmpeg/fftools/ffmpeg_opt.c:3202:15
#10 0x4d9d98 in ffmpeg_parse_options ffmpeg/fftools/ffmpeg_opt.c:3242:11
#11 0x50e98c in main ffmpeg/fftools/ffmpeg.c:4813:11
#12 0x7f9cf833cf44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287

The input file should be here:
https://bugs.chromium.org/p/chromium/issues/attachment?aid=177545

[...]

[Jacob Trimble]

On Wed, Jan 10, 2018 at 1:51 PM, Michael Niedermayer

Post by Michael Niedermayer
[...]
=================================================================
==4012==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eb78 at pc 0x000000a944aa bp 0x7ffcd481ce70 sp 0x7ffcd481ce68
READ of size 8 at 0x60200000eb78 thread T0
#0 0xa944a9 in mov_free_encryption_index ffmpeg/libavformat/mov.c:6615:20
#1 0xa6fb2b in mov_read_close ffmpeg/libavformat/mov.c:6693:13
#2 0xa6d96f in mov_read_header ffmpeg/libavformat/mov.c:6867:13
#3 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
#4 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1069:11
#5 0x4da0e7 in open_files ffmpeg/fftools/ffmpeg_opt.c:3202:15
#6 0x4d9d98 in ffmpeg_parse_options ffmpeg/fftools/ffmpeg_opt.c:3242:11
#7 0x50e98c in main ffmpeg/fftools/ffmpeg.c:4813:11
#8 0x7f9cf833cf44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287
#9 0x420da5 in _start (ffmpeg/ffmpeg_g+0x420da5)
0x60200000eb78 is located 4 bytes to the right of 4-byte region [0x60200000eb70,0x60200000eb74)
#0 0x4b126e in realloc (ffmpeg/ffmpeg_g+0x4b126e)
#1 0x218bbfe in av_strdup ffmpeg/libavutil/mem.c:256:15
#2 0x215eec1 in av_dict_set ffmpeg/libavutil/dict.c:87:22
#3 0x215f6e2 in av_dict_set_int ffmpeg/libavutil/dict.c:153:12
#4 0xa7644c in mov_read_ftyp ffmpeg/libavformat/mov.c:1109:5
#5 0xa6b153 in mov_read_default ffmpeg/libavformat/mov.c:6327:23
#6 0xa6c543 in mov_read_header ffmpeg/libavformat/mov.c:6865:20
#7 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
#8 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1069:11
#9 0x4da0e7 in open_files ffmpeg/fftools/ffmpeg_opt.c:3202:15
#10 0x4d9d98 in ffmpeg_parse_options ffmpeg/fftools/ffmpeg_opt.c:3242:11
#11 0x50e98c in main ffmpeg/fftools/ffmpeg.c:4813:11
#12 0x7f9cf833cf44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287
https://bugs.chromium.org/p/chromium/issues/attachment?aid=177545

Fixed.

Post by Michael Niedermayer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Jacob Trimble]

Post by Jacob Trimble
On Wed, Jan 10, 2018 at 1:51 PM, Michael Niedermayer

Post by Michael Niedermayer
[...]
=================================================================
==4012==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eb78 at pc 0x000000a944aa bp 0x7ffcd481ce70 sp 0x7ffcd481ce68
READ of size 8 at 0x60200000eb78 thread T0
#0 0xa944a9 in mov_free_encryption_index ffmpeg/libavformat/mov.c:6615:20
#1 0xa6fb2b in mov_read_close ffmpeg/libavformat/mov.c:6693:13
#2 0xa6d96f in mov_read_header ffmpeg/libavformat/mov.c:6867:13
#3 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
#4 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1069:11
#5 0x4da0e7 in open_files ffmpeg/fftools/ffmpeg_opt.c:3202:15
#6 0x4d9d98 in ffmpeg_parse_options ffmpeg/fftools/ffmpeg_opt.c:3242:11
#7 0x50e98c in main ffmpeg/fftools/ffmpeg.c:4813:11
#8 0x7f9cf833cf44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287
#9 0x420da5 in _start (ffmpeg/ffmpeg_g+0x420da5)
0x60200000eb78 is located 4 bytes to the right of 4-byte region [0x60200000eb70,0x60200000eb74)
#0 0x4b126e in realloc (ffmpeg/ffmpeg_g+0x4b126e)
#1 0x218bbfe in av_strdup ffmpeg/libavutil/mem.c:256:15
#2 0x215eec1 in av_dict_set ffmpeg/libavutil/dict.c:87:22
#3 0x215f6e2 in av_dict_set_int ffmpeg/libavutil/dict.c:153:12
#4 0xa7644c in mov_read_ftyp ffmpeg/libavformat/mov.c:1109:5
#5 0xa6b153 in mov_read_default ffmpeg/libavformat/mov.c:6327:23
#6 0xa6c543 in mov_read_header ffmpeg/libavformat/mov.c:6865:20
#7 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
#8 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1069:11
#9 0x4da0e7 in open_files ffmpeg/fftools/ffmpeg_opt.c:3202:15
#10 0x4d9d98 in ffmpeg_parse_options ffmpeg/fftools/ffmpeg_opt.c:3242:11
#11 0x50e98c in main ffmpeg/fftools/ffmpeg.c:4813:11
#12 0x7f9cf833cf44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287
https://bugs.chromium.org/p/chromium/issues/attachment?aid=177545

Fixed.

Post by Michael Niedermayer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Ping

[Michael Niedermayer]

Post by Jacob Trimble
On Wed, Jan 10, 2018 at 1:51 PM, Michael Niedermayer

Post by Michael Niedermayer
[...]
=================================================================
==4012==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eb78 at pc 0x000000a944aa bp 0x7ffcd481ce70 sp 0x7ffcd481ce68
READ of size 8 at 0x60200000eb78 thread T0
#0 0xa944a9 in mov_free_encryption_index ffmpeg/libavformat/mov.c:6615:20
#1 0xa6fb2b in mov_read_close ffmpeg/libavformat/mov.c:6693:13
#2 0xa6d96f in mov_read_header ffmpeg/libavformat/mov.c:6867:13
#3 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
#4 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1069:11
#5 0x4da0e7 in open_files ffmpeg/fftools/ffmpeg_opt.c:3202:15
#6 0x4d9d98 in ffmpeg_parse_options ffmpeg/fftools/ffmpeg_opt.c:3242:11
#7 0x50e98c in main ffmpeg/fftools/ffmpeg.c:4813:11
#8 0x7f9cf833cf44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287
#9 0x420da5 in _start (ffmpeg/ffmpeg_g+0x420da5)
0x60200000eb78 is located 4 bytes to the right of 4-byte region [0x60200000eb70,0x60200000eb74)
#0 0x4b126e in realloc (ffmpeg/ffmpeg_g+0x4b126e)
#1 0x218bbfe in av_strdup ffmpeg/libavutil/mem.c:256:15
#2 0x215eec1 in av_dict_set ffmpeg/libavutil/dict.c:87:22
#3 0x215f6e2 in av_dict_set_int ffmpeg/libavutil/dict.c:153:12
#4 0xa7644c in mov_read_ftyp ffmpeg/libavformat/mov.c:1109:5
#5 0xa6b153 in mov_read_default ffmpeg/libavformat/mov.c:6327:23
#6 0xa6c543 in mov_read_header ffmpeg/libavformat/mov.c:6865:20
#7 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
#8 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1069:11
#9 0x4da0e7 in open_files ffmpeg/fftools/ffmpeg_opt.c:3202:15
#10 0x4d9d98 in ffmpeg_parse_options ffmpeg/fftools/ffmpeg_opt.c:3242:11
#11 0x50e98c in main ffmpeg/fftools/ffmpeg.c:4813:11
#12 0x7f9cf833cf44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287
https://bugs.chromium.org/p/chromium/issues/attachment?aid=177545

Fixed.

Post by Michael Niedermayer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

libavformat/isom.h | 20 -
libavformat/mov.c | 432 ++++++++++++++++++++++-----------
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
5 files changed, 422 insertions(+), 152 deletions(-)
8dad9875df608b84def95d81c5c641db5ff88d43 0001-avformat-mov-Increase-support-for-v4.patch
From 5f6411a92569d13524485627fa68e62e8fd63e50 Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.
- Parse schm atom to get different encryption schemes.
- Allow senc atom to appear in track fragments.
- Allow 16-byte IVs.
- Allow constant IVs (specified in tenc).
- Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
- Use sample descriptor to detect clear fragments.
- Different sample descriptor holding different encryption info.
- Only first sample descriptor can be encrypted.
- Encrypted sample groups (i.e. seig).
- Non-'cenc' encryption scheme when using -decryption_key.
This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.

This removal should be done by a seperate patch if it is done.
diff has matched up the removed function with a added one making this
hard to read as is

Post by Jacob Trimble
---
libavformat/isom.h | 20 +-
libavformat/mov.c | 432 ++++++++++++++++++++++-----------
tests/fate/mov.mak | 8 +
tests/ref/fate/mov-frag-encrypted | 57 +++++
tests/ref/fate/mov-tenc-only-encrypted | 57 +++++
5 files changed, 422 insertions(+), 152 deletions(-)
create mode 100644 tests/ref/fate/mov-frag-encrypted
create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

This depends on other patches you posted, this should be mentioned or
all patches should be in the same patchset in order

Post by Jacob Trimble
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 65676fb0f5..3794b1f0fd 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -27,6 +27,7 @@
#include <stddef.h>
#include <stdint.h>
+#include "libavutil/encryption_info.h"
#include "libavutil/mastering_display_metadata.h"
#include "libavutil/spherical.h"
#include "libavutil/stereo3d.h"
@@ -108,12 +109,20 @@ typedef struct MOVSbgp {
unsigned int index;
} MOVSbgp;
+typedef struct MOVEncryptionIndex {
+ // Individual encrypted samples. If there are no elements, then the default
+ // settings will be used.
+ unsigned int nb_encrypted_samples;
+ AVEncryptionInfo **encrypted_samples;
+} MOVEncryptionIndex;
+
typedef struct MOVFragmentStreamInfo {
int id;
int64_t sidx_pts;
int64_t first_tfra_pts;
int64_t tfdt_dts;
int index_entry;
+ MOVEncryptionIndex *encryption_index;
} MOVFragmentStreamInfo;
typedef struct MOVFragmentIndexItem {
@@ -214,15 +223,10 @@ typedef struct MOVStreamContext {
int has_sidx; // If there is an sidx entry for this stream.
struct {
- int use_subsamples;
- uint8_t* auxiliary_info;
- uint8_t* auxiliary_info_end;
- uint8_t* auxiliary_info_pos;
- uint8_t auxiliary_info_default_size;
- uint8_t* auxiliary_info_sizes;
- size_t auxiliary_info_sizes_count;
- int64_t auxiliary_info_index;
struct AVAESCTR* aes_ctr;
+ unsigned int per_sample_iv_size; // Either 0, 8, or 16.
+ AVEncryptionInfo *default_encrypted_sample;
+ MOVEncryptionIndex *encryption_index;
} cenc;
} MOVStreamContext;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 22faecfc17..37320af2f6 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1324,6 +1324,7 @@ static int update_frag_index(MOVContext *c, int64_t offset)
frag_stream_info[i].tfdt_dts = AV_NOPTS_VALUE;
frag_stream_info[i].first_tfra_pts = AV_NOPTS_VALUE;
frag_stream_info[i].index_entry = -1;
+ frag_stream_info[i].encryption_index = NULL;
}
if (index < c->frag_index.nb_items)
@@ -5710,117 +5711,252 @@ static int mov_read_frma(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0;
}
-static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+/**
+ * Gets the current encryption info and associated current stream context. If
+ * we are parsing a track fragment, this will return the specific encryption
+ * info for this fragment; otherwise this will return the global encryption
+ * info for the current stream.
+ */
+static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encryption_index, MOVStreamContext **sc)
{
+ MOVFragmentStreamInfo *frag_stream_info;
AVStream *st;
- MOVStreamContext *sc;
- size_t auxiliary_info_size;
+ int i;
- if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
- return 0;
+ frag_stream_info = get_current_frag_stream_info(&c->frag_index);
+ if (frag_stream_info) {
+ for (i = 0; i < c->fc->nb_streams; i++) {
+ if (c->fc->streams[i]->id == frag_stream_info->id) {
+ st = c->fc->streams[i];
+ break;
+ }
+ }

the indention is inconsistent here


[...]

Post by Jacob Trimble
+static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+ AVEncryptionInfo **encrypted_samples;
+ MOVEncryptionIndex *encryption_index;
+ MOVStreamContext *sc;
+ int use_subsamples, ret;
+ unsigned int sample_count, i, alloc_size = 0;
- if (avio_read(pb, sc->cenc.auxiliary_info, auxiliary_info_size) != auxiliary_info_size) {
- av_log(c->fc, AV_LOG_ERROR, "failed to read the auxiliary info");
- return AVERROR_INVALIDDATA;
+ ret = get_current_encryption_info(c, &encryption_index, &sc);
+ if (ret != 1)
+ return ret;
+
+ if (encryption_index->nb_encrypted_samples) {
+ // This can happen if we have both saio/saiz and senc atoms.
+ av_log(c->fc, AV_LOG_DEBUG, "Ignoring duplicate encryption info in senc\n");
+ return 0;
}
- /* initialize the cipher */
- sc->cenc.aes_ctr = av_aes_ctr_alloc();
- if (!sc->cenc.aes_ctr) {
+ avio_r8(pb); /* version */
+ use_subsamples = avio_rb24(pb) & 0x02; /* flags */
+
+ sample_count = avio_rb32(pb);
+ if (sample_count >= INT_MAX / sizeof(*encrypted_samples))
return AVERROR(ENOMEM);
+
+ for (i = 0; i < sample_count && !pb->eof_reached; i++) {
+ unsigned int min_samples = FFMIN(FFMAX(i, 1024 * 1024), sample_count);
+ encrypted_samples = av_fast_realloc(encryption_index->encrypted_samples, &alloc_size,
+ min_samples * sizeof(*encrypted_samples));
+ if (!encrypted_samples) {
+ ret = AVERROR(ENOMEM);
+ goto end;
+ }
+ encryption_index->encrypted_samples = encrypted_samples;
+
+ ret = mov_read_sample_encryption_info(c, pb, sc, &encryption_index->encrypted_samples[i], use_subsamples);
+ if (ret < 0) {
+ goto end;
+ }
+ }
+
+ if (pb->eof_reached) {
+ av_log(c->fc, AV_LOG_ERROR, "Hit EOF while reading senc\n");
+ ret = AVERROR_INVALIDDATA;
}
- return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
+ if (ret < 0) {
+ for (; i > 0; i--)
+ av_encryption_info_free(encryption_index->encrypted_samples[i - 1]);

I think its a bit risky to use "i" here like this.
if someone adds a goto end before i is first used this breaks
if someone adds a loop after the main loop this breaks too

[...]

[Jacob Trimble]

On Mon, Jan 22, 2018 at 7:38 PM, Michael Niedermayer

Post by Michael Niedermayer
[...]

Post by Jacob Trimble
This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.

This removal should be done by a seperate patch if it is done.
diff has matched up the removed function with a added one making this
hard to read as is

The problem is that the old code used the saiz atoms to parse the senc
atom. I split the patch up for readability, but the two patches need
to be applied at the same time (or squashed) since the first breaks
encrypted content. But I can squash them again if it is preferable to
not have a commit that intentionally breaks things.

Post by Michael Niedermayer

Post by Jacob Trimble
---
libavformat/isom.h | 20 +-
libavformat/mov.c | 432 ++++++++++++++++++++++-----------
tests/fate/mov.mak | 8 +
tests/ref/fate/mov-frag-encrypted | 57 +++++
tests/ref/fate/mov-tenc-only-encrypted | 57 +++++
5 files changed, 422 insertions(+), 152 deletions(-)
create mode 100644 tests/ref/fate/mov-frag-encrypted
create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

This depends on other patches you posted, this should be mentioned or
all patches should be in the same patchset in order

This depends on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html and
the recently pushed change to libavutil/aes_ctr. Should I add
something to the commit message or is that enough?

Post by Michael Niedermayer

Post by Jacob Trimble
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 65676fb0f5..3794b1f0fd 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -27,6 +27,7 @@
#include <stddef.h>
#include <stdint.h>
+#include "libavutil/encryption_info.h"
#include "libavutil/mastering_display_metadata.h"
#include "libavutil/spherical.h"
#include "libavutil/stereo3d.h"
@@ -108,12 +109,20 @@ typedef struct MOVSbgp {
unsigned int index;
} MOVSbgp;
+typedef struct MOVEncryptionIndex {
+ // Individual encrypted samples. If there are no elements, then the default
+ // settings will be used.
+ unsigned int nb_encrypted_samples;
+ AVEncryptionInfo **encrypted_samples;
+} MOVEncryptionIndex;
+
typedef struct MOVFragmentStreamInfo {
int id;
int64_t sidx_pts;
int64_t first_tfra_pts;
int64_t tfdt_dts;
int index_entry;
+ MOVEncryptionIndex *encryption_index;
} MOVFragmentStreamInfo;
typedef struct MOVFragmentIndexItem {
@@ -214,15 +223,10 @@ typedef struct MOVStreamContext {
int has_sidx; // If there is an sidx entry for this stream.
struct {
- int use_subsamples;
- uint8_t* auxiliary_info;
- uint8_t* auxiliary_info_end;
- uint8_t* auxiliary_info_pos;
- uint8_t auxiliary_info_default_size;
- uint8_t* auxiliary_info_sizes;
- size_t auxiliary_info_sizes_count;
- int64_t auxiliary_info_index;
struct AVAESCTR* aes_ctr;
+ unsigned int per_sample_iv_size; // Either 0, 8, or 16.
+ AVEncryptionInfo *default_encrypted_sample;
+ MOVEncryptionIndex *encryption_index;
} cenc;
} MOVStreamContext;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 22faecfc17..37320af2f6 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1324,6 +1324,7 @@ static int update_frag_index(MOVContext *c, int64_t offset)
frag_stream_info[i].tfdt_dts = AV_NOPTS_VALUE;
frag_stream_info[i].first_tfra_pts = AV_NOPTS_VALUE;
frag_stream_info[i].index_entry = -1;
+ frag_stream_info[i].encryption_index = NULL;
}
if (index < c->frag_index.nb_items)
@@ -5710,117 +5711,252 @@ static int mov_read_frma(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0;
}
-static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+/**
+ * Gets the current encryption info and associated current stream context. If
+ * we are parsing a track fragment, this will return the specific encryption
+ * info for this fragment; otherwise this will return the global encryption
+ * info for the current stream.
+ */
+static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encryption_index, MOVStreamContext **sc)
{
+ MOVFragmentStreamInfo *frag_stream_info;
AVStream *st;
- MOVStreamContext *sc;
- size_t auxiliary_info_size;
+ int i;
- if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
- return 0;
+ frag_stream_info = get_current_frag_stream_info(&c->frag_index);
+ if (frag_stream_info) {
+ for (i = 0; i < c->fc->nb_streams; i++) {
+ if (c->fc->streams[i]->id == frag_stream_info->id) {
+ st = c->fc->streams[i];
+ break;
+ }
+ }

the indention is inconsistent here

No it's not, it looks like it because the diff looks odd. If you
apply the patch, the indentation in this method is consistent.

Post by Michael Niedermayer
[...]

Post by Jacob Trimble
+static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+ AVEncryptionInfo **encrypted_samples;
+ MOVEncryptionIndex *encryption_index;
+ MOVStreamContext *sc;
+ int use_subsamples, ret;
+ unsigned int sample_count, i, alloc_size = 0;
- if (avio_read(pb, sc->cenc.auxiliary_info, auxiliary_info_size) != auxiliary_info_size) {
- av_log(c->fc, AV_LOG_ERROR, "failed to read the auxiliary info");
- return AVERROR_INVALIDDATA;
+ ret = get_current_encryption_info(c, &encryption_index, &sc);
+ if (ret != 1)
+ return ret;
+
+ if (encryption_index->nb_encrypted_samples) {
+ // This can happen if we have both saio/saiz and senc atoms.
+ av_log(c->fc, AV_LOG_DEBUG, "Ignoring duplicate encryption info in senc\n");
+ return 0;
}
- /* initialize the cipher */
- sc->cenc.aes_ctr = av_aes_ctr_alloc();
- if (!sc->cenc.aes_ctr) {
+ avio_r8(pb); /* version */
+ use_subsamples = avio_rb24(pb) & 0x02; /* flags */
+
+ sample_count = avio_rb32(pb);
+ if (sample_count >= INT_MAX / sizeof(*encrypted_samples))
return AVERROR(ENOMEM);
+
+ for (i = 0; i < sample_count && !pb->eof_reached; i++) {
+ unsigned int min_samples = FFMIN(FFMAX(i, 1024 * 1024), sample_count);
+ encrypted_samples = av_fast_realloc(encryption_index->encrypted_samples, &alloc_size,
+ min_samples * sizeof(*encrypted_samples));
+ if (!encrypted_samples) {
+ ret = AVERROR(ENOMEM);
+ goto end;
+ }
+ encryption_index->encrypted_samples = encrypted_samples;
+
+ ret = mov_read_sample_encryption_info(c, pb, sc, &encryption_index->encrypted_samples[i], use_subsamples);
+ if (ret < 0) {
+ goto end;
+ }
+ }
+
+ if (pb->eof_reached) {
+ av_log(c->fc, AV_LOG_ERROR, "Hit EOF while reading senc\n");
+ ret = AVERROR_INVALIDDATA;
}
- return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
+ if (ret < 0) {
+ for (; i > 0; i--)
+ av_encryption_info_free(encryption_index->encrypted_samples[i - 1]);

I think its a bit risky to use "i" here like this.
if someone adds a goto end before i is first used this breaks
if someone adds a loop after the main loop this breaks too

Yeah, you're right. Changed to free the partial array in the loop.

Post by Michael Niedermayer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Michael Niedermayer]

Post by Jacob Trimble
On Mon, Jan 22, 2018 at 7:38 PM, Michael Niedermayer

Post by Michael Niedermayer
[...]

Post by Jacob Trimble
This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.

This removal should be done by a seperate patch if it is done.
diff has matched up the removed function with a added one making this
hard to read as is

The problem is that the old code used the saiz atoms to parse the senc
atom. I split the patch up for readability, but the two patches need
to be applied at the same time (or squashed) since the first breaks
encrypted content. But I can squash them again if it is preferable to
not have a commit that intentionally breaks things.

I didnt investigate this deeply so there is likely a better option that
i miss but you could just remove the functions which become unused in a
subsequent patch to prevent diff from messing the line matching up totally

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
---
libavformat/isom.h | 20 +-
libavformat/mov.c | 432 ++++++++++++++++++++++-----------
tests/fate/mov.mak | 8 +
tests/ref/fate/mov-frag-encrypted | 57 +++++
tests/ref/fate/mov-tenc-only-encrypted | 57 +++++
5 files changed, 422 insertions(+), 152 deletions(-)
create mode 100644 tests/ref/fate/mov-frag-encrypted
create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

This depends on other patches you posted, this should be mentioned or
all patches should be in the same patchset in order

This depends on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html and
the recently pushed change to libavutil/aes_ctr. Should I add
something to the commit message or is that enough?

If you post a new version, then there should be a mail or comment explaining
any dependancies on yet to be applied patches.
It should not be in the commit messages or commited changes ideally
This way people trying to test code dont need to guess what they need
to apply first before a patchset


[...]

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
+static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encryption_index, MOVStreamContext **sc)
{
+ MOVFragmentStreamInfo *frag_stream_info;
AVStream *st;
- MOVStreamContext *sc;
- size_t auxiliary_info_size;
+ int i;
- if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
- return 0;
+ frag_stream_info = get_current_frag_stream_info(&c->frag_index);
+ if (frag_stream_info) {
+ for (i = 0; i < c->fc->nb_streams; i++) {
+ if (c->fc->streams[i]->id == frag_stream_info->id) {
+ st = c->fc->streams[i];
+ break;
+ }
+ }

the indention is inconsistent here

No it's not, it looks like it because the diff looks odd. If you
apply the patch, the indentation in this method is consistent.

Indention depth is 4 in mov*.c
the hunk seems to add lines with a depth of 2
I would be surprised if this is not in the file after applying the patch

personally i dont care about the depth that much but i know many other people
care so this needs to be fixed before this can be applied

[...]

[Jacob Trimble]

On Wed, Jan 24, 2018 at 5:46 PM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble
On Mon, Jan 22, 2018 at 7:38 PM, Michael Niedermayer

Post by Michael Niedermayer
[...]

Post by Jacob Trimble
This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.

This removal should be done by a seperate patch if it is done.
diff has matched up the removed function with a added one making this
hard to read as is

The problem is that the old code used the saiz atoms to parse the senc
atom. I split the patch up for readability, but the two patches need
to be applied at the same time (or squashed) since the first breaks
encrypted content. But I can squash them again if it is preferable to
not have a commit that intentionally breaks things.

I didnt investigate this deeply so there is likely a better option that
i miss but you could just remove the functions which become unused in a
subsequent patch to prevent diff from messing the line matching up totally

Done.

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
---
libavformat/isom.h | 20 +-
libavformat/mov.c | 432 ++++++++++++++++++++++-----------
tests/fate/mov.mak | 8 +
tests/ref/fate/mov-frag-encrypted | 57 +++++
tests/ref/fate/mov-tenc-only-encrypted | 57 +++++
5 files changed, 422 insertions(+), 152 deletions(-)
create mode 100644 tests/ref/fate/mov-frag-encrypted
create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

This depends on other patches you posted, this should be mentioned or
all patches should be in the same patchset in order

This depends on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html and
the recently pushed change to libavutil/aes_ctr. Should I add
something to the commit message or is that enough?

If you post a new version, then there should be a mail or comment explaining
any dependancies on yet to be applied patches.
It should not be in the commit messages or commited changes ideally
This way people trying to test code dont need to guess what they need
to apply first before a patchset
[...]

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
+static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encryption_index, MOVStreamContext **sc)
{
+ MOVFragmentStreamInfo *frag_stream_info;
AVStream *st;
- MOVStreamContext *sc;
- size_t auxiliary_info_size;
+ int i;
- if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
- return 0;
+ frag_stream_info = get_current_frag_stream_info(&c->frag_index);
+ if (frag_stream_info) {
+ for (i = 0; i < c->fc->nb_streams; i++) {
+ if (c->fc->streams[i]->id == frag_stream_info->id) {
+ st = c->fc->streams[i];
+ break;
+ }
+ }

the indention is inconsistent here

No it's not, it looks like it because the diff looks odd. If you
apply the patch, the indentation in this method is consistent.

Indention depth is 4 in mov*.c
the hunk seems to add lines with a depth of 2
I would be surprised if this is not in the file after applying the patch
personally i dont care about the depth that much but i know many other people
care so this needs to be fixed before this can be applied

Didn't see that. Fixed and did a grep for incorrect indentations.

Post by Michael Niedermayer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Jacob Trimble]

Post by Jacob Trimble
On Wed, Jan 24, 2018 at 5:46 PM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble
On Mon, Jan 22, 2018 at 7:38 PM, Michael Niedermayer

Post by Michael Niedermayer
[...]

Post by Jacob Trimble
This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.

This removal should be done by a seperate patch if it is done.
diff has matched up the removed function with a added one making this
hard to read as is

The problem is that the old code used the saiz atoms to parse the senc
atom. I split the patch up for readability, but the two patches need
to be applied at the same time (or squashed) since the first breaks
encrypted content. But I can squash them again if it is preferable to
not have a commit that intentionally breaks things.

I didnt investigate this deeply so there is likely a better option that
i miss but you could just remove the functions which become unused in a
subsequent patch to prevent diff from messing the line matching up totally

Done.

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
---
libavformat/isom.h | 20 +-
libavformat/mov.c | 432 ++++++++++++++++++++++-----------
tests/fate/mov.mak | 8 +
tests/ref/fate/mov-frag-encrypted | 57 +++++
tests/ref/fate/mov-tenc-only-encrypted | 57 +++++
5 files changed, 422 insertions(+), 152 deletions(-)
create mode 100644 tests/ref/fate/mov-frag-encrypted
create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

This depends on other patches you posted, this should be mentioned or
all patches should be in the same patchset in order

This depends on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html and
the recently pushed change to libavutil/aes_ctr. Should I add
something to the commit message or is that enough?

If you post a new version, then there should be a mail or comment explaining
any dependancies on yet to be applied patches.
It should not be in the commit messages or commited changes ideally
This way people trying to test code dont need to guess what they need
to apply first before a patchset
[...]

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
+static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encryption_index, MOVStreamContext **sc)
{
+ MOVFragmentStreamInfo *frag_stream_info;
AVStream *st;
- MOVStreamContext *sc;
- size_t auxiliary_info_size;
+ int i;
- if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
- return 0;
+ frag_stream_info = get_current_frag_stream_info(&c->frag_index);
+ if (frag_stream_info) {
+ for (i = 0; i < c->fc->nb_streams; i++) {
+ if (c->fc->streams[i]->id == frag_stream_info->id) {
+ st = c->fc->streams[i];
+ break;
+ }
+ }

the indention is inconsistent here

No it's not, it looks like it because the diff looks odd. If you
apply the patch, the indentation in this method is consistent.

Indention depth is 4 in mov*.c
the hunk seems to add lines with a depth of 2
I would be surprised if this is not in the file after applying the patch
personally i dont care about the depth that much but i know many other people
care so this needs to be fixed before this can be applied

Didn't see that. Fixed and did a grep for incorrect indentations.

Post by Michael Niedermayer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Ping. This depends on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html.

[Jacob Trimble]

Post by Jacob Trimble

Post by Jacob Trimble
On Wed, Jan 24, 2018 at 5:46 PM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble
On Mon, Jan 22, 2018 at 7:38 PM, Michael Niedermayer

Post by Michael Niedermayer
[...]

Post by Jacob Trimble
This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.

This removal should be done by a seperate patch if it is done.
diff has matched up the removed function with a added one making this
hard to read as is

The problem is that the old code used the saiz atoms to parse the senc
atom. I split the patch up for readability, but the two patches need
to be applied at the same time (or squashed) since the first breaks
encrypted content. But I can squash them again if it is preferable to
not have a commit that intentionally breaks things.

I didnt investigate this deeply so there is likely a better option that
i miss but you could just remove the functions which become unused in a
subsequent patch to prevent diff from messing the line matching up totally

Done.

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
---
libavformat/isom.h | 20 +-
libavformat/mov.c | 432 ++++++++++++++++++++++-----------
tests/fate/mov.mak | 8 +
tests/ref/fate/mov-frag-encrypted | 57 +++++
tests/ref/fate/mov-tenc-only-encrypted | 57 +++++
5 files changed, 422 insertions(+), 152 deletions(-)
create mode 100644 tests/ref/fate/mov-frag-encrypted
create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

This depends on other patches you posted, this should be mentioned or
all patches should be in the same patchset in order

This depends on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html and
the recently pushed change to libavutil/aes_ctr. Should I add
something to the commit message or is that enough?

If you post a new version, then there should be a mail or comment explaining
any dependancies on yet to be applied patches.
It should not be in the commit messages or commited changes ideally
This way people trying to test code dont need to guess what they need
to apply first before a patchset
[...]

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
+static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encryption_index, MOVStreamContext **sc)
{
+ MOVFragmentStreamInfo *frag_stream_info;
AVStream *st;
- MOVStreamContext *sc;
- size_t auxiliary_info_size;
+ int i;
- if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
- return 0;
+ frag_stream_info = get_current_frag_stream_info(&c->frag_index);
+ if (frag_stream_info) {
+ for (i = 0; i < c->fc->nb_streams; i++) {
+ if (c->fc->streams[i]->id == frag_stream_info->id) {
+ st = c->fc->streams[i];
+ break;
+ }
+ }

the indention is inconsistent here

No it's not, it looks like it because the diff looks odd. If you
apply the patch, the indentation in this method is consistent.

Indention depth is 4 in mov*.c
the hunk seems to add lines with a depth of 2
I would be surprised if this is not in the file after applying the patch
personally i dont care about the depth that much but i know many other people
care so this needs to be fixed before this can be applied

Didn't see that. Fixed and did a grep for incorrect indentations.

Post by Michael Niedermayer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Ping. This depends on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html.

Ping again. I know this is low priority, but I would like to get
these merged soon.

[Jacob Trimble]

Post by Jacob Trimble

Post by Jacob Trimble

Post by Jacob Trimble
On Wed, Jan 24, 2018 at 5:46 PM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble
On Mon, Jan 22, 2018 at 7:38 PM, Michael Niedermayer

Post by Michael Niedermayer
[...]

Post by Jacob Trimble
This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.

This removal should be done by a seperate patch if it is done.
diff has matched up the removed function with a added one making this
hard to read as is

The problem is that the old code used the saiz atoms to parse the senc
atom. I split the patch up for readability, but the two patches need
to be applied at the same time (or squashed) since the first breaks
encrypted content. But I can squash them again if it is preferable to
not have a commit that intentionally breaks things.

I didnt investigate this deeply so there is likely a better option that
i miss but you could just remove the functions which become unused in a
subsequent patch to prevent diff from messing the line matching up totally

Done.

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
---
libavformat/isom.h | 20 +-
libavformat/mov.c | 432 ++++++++++++++++++++++-----------
tests/fate/mov.mak | 8 +
tests/ref/fate/mov-frag-encrypted | 57 +++++
tests/ref/fate/mov-tenc-only-encrypted | 57 +++++
5 files changed, 422 insertions(+), 152 deletions(-)
create mode 100644 tests/ref/fate/mov-frag-encrypted
create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

This depends on other patches you posted, this should be mentioned or
all patches should be in the same patchset in order

This depends on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html and
the recently pushed change to libavutil/aes_ctr. Should I add
something to the commit message or is that enough?

If you post a new version, then there should be a mail or comment explaining
any dependancies on yet to be applied patches.
It should not be in the commit messages or commited changes ideally
This way people trying to test code dont need to guess what they need
to apply first before a patchset
[...]

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
+static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encryption_index, MOVStreamContext **sc)
{
+ MOVFragmentStreamInfo *frag_stream_info;
AVStream *st;
- MOVStreamContext *sc;
- size_t auxiliary_info_size;
+ int i;
- if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
- return 0;
+ frag_stream_info = get_current_frag_stream_info(&c->frag_index);
+ if (frag_stream_info) {
+ for (i = 0; i < c->fc->nb_streams; i++) {
+ if (c->fc->streams[i]->id == frag_stream_info->id) {
+ st = c->fc->streams[i];
+ break;
+ }
+ }

the indention is inconsistent here

No it's not, it looks like it because the diff looks odd. If you
apply the patch, the indentation in this method is consistent.

Indention depth is 4 in mov*.c
the hunk seems to add lines with a depth of 2
I would be surprised if this is not in the file after applying the patch
personally i dont care about the depth that much but i know many other people
care so this needs to be fixed before this can be applied

Didn't see that. Fixed and did a grep for incorrect indentations.

Post by Michael Niedermayer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Ping. This depends on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html.

Ping again. I know this is low priority, but I would like to get
these merged soon.

Ping. Despite being almost 2 months old, these patches still apply
cleanly. Please take a look. These have been in review for almost 3
months.

[Jacob Trimble]

Post by Jacob Trimble

Post by Jacob Trimble
Ping again. I know this is low priority, but I would like to get
these merged soon.

Ping. Despite being almost 2 months old, these patches still apply
cleanly. Please take a look. These have been in review for almost 3
months.

Ping (going to keep pinging this until someone merges this or tells me
why not). Day after tomorrow this will be in review for 4 months!!!

Also noticed a bug when integrating this, so here is an updated patch.

[Michael Niedermayer]

Post by Jacob Trimble

Post by Jacob Trimble

Post by Jacob Trimble
Ping again. I know this is low priority, but I would like to get
these merged soon.

Ping. Despite being almost 2 months old, these patches still apply
cleanly. Please take a look. These have been in review for almost 3
months.

Ping (going to keep pinging this until someone merges this or tells me
why not). Day after tomorrow this will be in review for 4 months!!!
Also noticed a bug when integrating this, so here is an updated patch.
libavformat/isom.h | 14 +
libavformat/mov.c | 396 ++++++++++++++++++++++++++-------
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
5 files changed, 450 insertions(+), 82 deletions(-)
9f1b7e04bc8001ad9faa59485090189f529cbf24 0001-avformat-mov-Increase-support-for-v7.patch
From 282effab6026341c49a52950cf8ba11afc9dc6aa Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

maybe iam missing something but applying this to master seems to cause
fate to fail


--- ./tests/ref/fate/mov-3elist-encrypted 2018-04-17 14:20:30.560366780 +0200
+++ tests/data/fate/mov-3elist-encrypted 2018-04-18 03:53:32.872157901 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 640x480
-#sar 0: 0/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 460800, 80fbbdec589e15e6c493b44d243f92a9
-0, 1, 1, 1, 460800, f4b23293bb2ecf69cc3570853d8c56a1
-0, 2, 2, 1, 460800, 0c03ce2c1c6ec405d7455465ecd559a3
-0, 3, 3, 1, 460800, 7921791695537fba2c3c123da4834cb9
-0, 4, 4, 1, 460800, 30c8e2903a561b84d4cbaf95c668d236
-0, 5, 5, 1, 460800, 7ff42e998217c17592ddf6b584f26cef
-0, 6, 6, 1, 460800, 5e402c48bf097db2d31b82bb4194a382
-0, 7, 7, 1, 460800, 824c49e92c8ae6d99a0207b514dd756c
-0, 8, 8, 1, 460800, 24f189216a1d9cf2313b2d6dbe3dbdd3
-0, 9, 9, 1, 460800, 519179a8e74275d26b183374637e003f
-0, 10, 10, 1, 460800, f18331ddcef0adf5b069bfa98baf8db4
-0, 11, 11, 1, 460800, 081f61688690d47dbdddd5384e5d5a70
-0, 12, 12, 1, 460800, 90dbf019b9035433371a8df41a9268b7
-0, 13, 13, 1, 460800, bb5adfb9c66732898b34186eca1667ba
-0, 14, 14, 1, 460800, cc08cfd64f37783ecddaf143f6ad78bc
-0, 15, 15, 1, 460800, b8ae21d024fe4df903d56f4521993c72
-0, 16, 16, 1, 460800, b45a99907f045dcadf0a2befc11555e3
-0, 17, 17, 1, 460800, 603ba935845e65ab6cccbbec88bbf60d
-0, 18, 18, 1, 460800, df80c8d3e6a77258a306903f17995a18
-0, 19, 19, 1, 460800, 4b7e90c0a5fd0e0cd958d47f0afac636
-0, 20, 20, 1, 460800, 9feb6e36182f1745be6387edea240eb6
-0, 21, 21, 1, 460800, 86e6de4bd0a5ff7558f4cf6c1ec3930d
-0, 22, 22, 1, 460800, 726b69df77edbe7b503d4698656d1320
-0, 23, 23, 1, 460800, d282fb7a953ac205b0a43d00c2d60a33
-0, 24, 24, 1, 460800, eece3daa70cc20208dd75d91ac84c8fd
-0, 25, 25, 1, 460800, c86d23e73bcce351fc315fb1f13348da
-0, 26, 26, 1, 460800, 93497b4f7c5ad9d61212239b7c9d2770
-0, 27, 27, 1, 460800, eb217d2c12de67903835a8c58f620488
-0, 28, 28, 1, 460800, d966480867bb54c8cd044f18388ed486
-0, 29, 29, 1, 460800, 3ea6207942b3181fdd8e8aa6cae1062a
-0, 30, 30, 1, 460800, 2620df54aca086ec0fb9527c6e6f5135
-0, 31, 31, 1, 460800, 43bb7320f0bb583188dc965ddbfade90
-0, 32, 32, 1, 460800, 0cddaa04645f804e02f65b0836412113
-0, 33, 33, 1, 460800, 83b2dc95807289d7f4a4632bf18c2e97
-0, 34, 34, 1, 460800, 98134d0e41e6dd12827049ccf33b4669
-0, 35, 35, 1, 460800, 56f55631731fa39c7acbab0afeb2eb1b
-0, 36, 36, 1, 460800, 379c1105be09d836a515dc909455ddf4
-0, 37, 37, 1, 460800, 1df87c47e9d98731faf1c3885b77e5da
-0, 38, 38, 1, 460800, 9a8734bcbfdb4d97e530683b8b556a26
-0, 39, 39, 1, 460800, c7a7990d0cddc5adfbe27da7a42e025e
-0, 40, 40, 1, 460800, 0c81e46011e03be410feaf056207fd55
-0, 41, 41, 1, 460800, ca76e4e63016ff29d8aeeb9cb053bb6c
-0, 42, 42, 1, 460800, cebfbe299c17c1f8fc1e6b189555c3c2
-0, 43, 43, 1, 460800, 4f002c5feca5e75f07089e0df47507dd
-0, 44, 44, 1, 460800, c5fd83fc4a745abee9b3d9a6eec9dd3e
-0, 45, 45, 1, 460800, 57d9bad9b45aa2746de5d8bdc2c24969
-0, 46, 46, 1, 460800, 9831673ad7dec167af4a959f64258949
-0, 47, 47, 1, 460800, 77a1cb208f70f51bcb01e28d8cba73b4
Test mov-3elist-encrypted failed. Look at tests/data/fate/mov-3elist-encrypted.err for details.
make: *** [fate-mov-3elist-encrypted] Error 1
TEST mov-gpmf-remux
--- ./tests/ref/fate/mov-frag-encrypted 2018-04-18 03:27:04.860164700 +0200
+++ tests/data/fate/mov-frag-encrypted 2018-04-18 03:53:32.984157900 +0200
@@ -31,27 +31,3 @@
0, 21, 21, 1, 9360, e96af3b6c0cc931463ca77d6be0f1148
0, 22, 22, 1, 9360, 04a904d798361959971361401879c7e4
0, 23, 23, 1, 9360, 2f119642340df6d25362b5590ded46b7
-0, 24, 24, 1, 9360, 5993fca2e60050706f857ac76e48f386
-0, 25, 25, 1, 9360, 2ff3b5775fed3d527bfbbeea786787fe
-0, 26, 26, 1, 9360, 42024dbe23d3fb5b0d8987ae1ce390a8
-0, 27, 27, 1, 9360, d804204f0bd9db5f6a758e2c934d9e38
-0, 28, 28, 1, 9360, e322712e6e34c58ec1a2ab5e2c1e3bfe
-0, 29, 29, 1, 9360, 3975bd1a5f6a6b6260276777f9de611e
-0, 30, 30, 1, 9360, 4388f0412efc6310706a7cdedc859ea9
-0, 31, 31, 1, 9360, b4b9a11b0b86635267345a569640e8d4
-0, 32, 32, 1, 9360, 31879c7b8d6b67a4209ffde786bb8cb4
-0, 33, 33, 1, 9360, 4b6dc02d7c889fe4abd4e013b25f585a
-0, 34, 34, 1, 9360, dc73aae82bd39a1220d1106c8d3e8252
-0, 35, 35, 1, 9360, 54c7dfbd49f312806f6c1a89f7c2c36f
-0, 36, 36, 1, 9360, 150abc64f8994d444a521ea90570443c
-0, 37, 37, 1, 9360, d277cdc7dcadbe0016f2e950459e7ebf
-0, 38, 38, 1, 9360, 2196bf338ead90ea54687b85c73c8229
-0, 39, 39, 1, 9360, 53ce5da5365abc0bd3217dd98e7c465d
-0, 40, 40, 1, 9360, 34ee9832aea55c0c4e6f4381c413c10e
-0, 41, 41, 1, 9360, 1769c7b5849e4681119067a06ac29a4f
-0, 42, 42, 1, 9360, 71f53df739ef283a5184c91ef4b158e8
-0, 43, 43, 1, 9360, d2d394739e9a59c06f0354c16843cb63
-0, 44, 44, 1, 9360, d8e458e92ae29344505a24a3059fc584
-0, 45, 45, 1, 9360, 0f1b11a09911851b798df2ef76253a7f
-0, 46, 46, 1, 9360, 5c4a9f22baecf4e749c0d5c65a4f1007
-0, 47, 47, 1, 9360, 3e2b7e7262fdca08d9d1ef6070125c4b
Test mov-frag-encrypted failed. Look at tests/data/fate/mov-frag-encrypted.err for details.
make: *** [fate-mov-frag-encrypted] Error 1
TEST mov-440hz-10ms
TEST mov-ibi-elst-starts-b
TEST mov-elst-ends-betn-b-and-i
--- ./tests/ref/fate/mov-tenc-only-encrypted 2018-04-18 03:27:04.868164700 +0200
+++ tests/data/fate/mov-tenc-only-encrypted 2018-04-18 03:53:32.932157900 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 1024x436
-#sar 0: 1/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 669696, f48f296a85eda5ba069dc851a3228bef
-0, 1, 1, 1, 669696, a50c5f69bfa3387d49b5bdf738e6529c
-0, 2, 2, 1, 669696, 05061299003760f6a4795b408f72aa31
-0, 3, 3, 1, 669696, 2572119f0b0cdd83f8a7e06252cecd3b
-0, 4, 4, 1, 669696, 29fe6a6bdb4a69018e318886a297f07e
-0, 5, 5, 1, 669696, e8233c7fbaecfbff965c7dfdd3982b1b
-0, 6, 6, 1, 669696, d9259df9880ff5d4a4b38282e67f407b
-0, 7, 7, 1, 669696, 3e8d795195038993503ea9ab6984c915
-0, 8, 8, 1, 669696, bc4e2d253b715a34f85aae1b080e3460
-0, 9, 9, 1, 669696, 09aba8b3a96f53f9268e7420a10bfab6
-0, 10, 10, 1, 669696, 179447977dd580da8b35fb5310a809ca
-0, 11, 11, 1, 669696, 7a0eea9d54577990345f5705ab9882be
-0, 12, 12, 1, 669696, 5bb96eb76f461825740e5938456df759
-0, 13, 13, 1, 669696, bd4ac4a760ead774b9422a27dc071964
-0, 14, 14, 1, 669696, 1cc05f760a9b751fc89e77f2bcc97259
-0, 15, 15, 1, 669696, 825d0dee6f0174ba7102892c7de30b4d
-0, 16, 16, 1, 669696, d26a2ef5267f6bb03c4e1d8514eee0df
-0, 17, 17, 1, 669696, c916ffdeadca76596a8f7fd47914b5ef
-0, 18, 18, 1, 669696, 6e085acfa7fee0658ea0ae6188274c17
-0, 19, 19, 1, 669696, 1e95fa5b3561283f05bf0bd44cb91721
-0, 20, 20, 1, 669696, 37e3d135aba9dfb8b87e441753115374
-0, 21, 21, 1, 669696, 9c398310e8564491de624393c16265ce
-0, 22, 22, 1, 669696, c87209e4d2617bc2ab40a75f455f09da
-0, 23, 23, 1, 669696, 2679c2f8d1d1af21982e245945c1ee60
-0, 24, 24, 1, 669696, 6151ab4781f31c5beb66b356ad547122
-0, 25, 25, 1, 669696, f7ef6293bfb3a6a329061cb6a5ed5a38
-0, 26, 26, 1, 669696, 2f6e666d14dfc407ca0c0f347b13eb08
-0, 27, 27, 1, 669696, 3454fa1730d79b1aa8dbbc865dc150f4
-0, 28, 28, 1, 669696, e93dc683e2453419a0419ab9af0f8f95
-0, 29, 29, 1, 669696, 031eb3154f7f83cf86d42bee66be9cf7
-0, 30, 30, 1, 669696, 1205c36723e88811206c68892d3aaed6
-0, 31, 31, 1, 669696, 7dd7a8a19dcd73b31ddc6a6d0c597a42
-0, 32, 32, 1, 669696, 7c91115368ea2531262a1197468bc3f4
-0, 33, 33, 1, 669696, 3cf6d9ba385e0fff76da33299ed5380c
-0, 34, 34, 1, 669696, 859fc8c3ef049e3c1175a85fb0a90a3d
-0, 35, 35, 1, 669696, 1d09ce6c7027103d99a4d5799f6e72ab
-0, 36, 36, 1, 669696, 3dcb8357408ac88abd734128d8f5dd6f
-0, 37, 37, 1, 669696, 4dafce137a0a5178f6efaec878e64d36
-0, 38, 38, 1, 669696, 44c478f29a1399ed03275a7357f57d48
-0, 39, 39, 1, 669696, 6e9edaac7414c0e14591ac3d4d0b1ac4
-0, 40, 40, 1, 669696, 522e4aaeea0825da27f631a9e690d654
-0, 41, 41, 1, 669696, 85f2502a718440834c40051d30f8a65e
-0, 42, 42, 1, 669696, ae8816f7bd4645ef1a17ee6d09b4c8d2
-0, 43, 43, 1, 669696, 914b006fa92f1eb3e590245749f6810d
-0, 44, 44, 1, 669696, 9406901542e94c429dff46108782ed69
-0, 45, 45, 1, 669696, 324c13641c39eef5c476023e358c0391
-0, 46, 46, 1, 669696, 4058e886e17c22e4eb9da1dd0d6ad891
-0, 47, 47, 1, 669696, 9edf9cd15eea985b42fd1f5035b1d693
Test mov-tenc-only-encrypted failed. Look at tests/data/fate/mov-tenc-only-encrypted.err for details.
make: *** [fate-mov-tenc-only-encrypted] Error 1

[...]

[Jacob Trimble]

On Tue, Apr 17, 2018 at 7:11 PM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Jacob Trimble

Post by Jacob Trimble
Ping again. I know this is low priority, but I would like to get
these merged soon.

Ping. Despite being almost 2 months old, these patches still apply
cleanly. Please take a look. These have been in review for almost 3
months.

Ping (going to keep pinging this until someone merges this or tells me
why not). Day after tomorrow this will be in review for 4 months!!!
Also noticed a bug when integrating this, so here is an updated patch.
libavformat/isom.h | 14 +
libavformat/mov.c | 396 ++++++++++++++++++++++++++-------
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
5 files changed, 450 insertions(+), 82 deletions(-)
9f1b7e04bc8001ad9faa59485090189f529cbf24 0001-avformat-mov-Increase-support-for-v7.patch
From 282effab6026341c49a52950cf8ba11afc9dc6aa Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

maybe iam missing something but applying this to master seems to cause
fate to fail
--- ./tests/ref/fate/mov-3elist-encrypted 2018-04-17 14:20:30.560366780 +0200
+++ tests/data/fate/mov-3elist-encrypted 2018-04-18 03:53:32.872157901 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 640x480
-#sar 0: 0/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 460800, 80fbbdec589e15e6c493b44d243f92a9
-0, 1, 1, 1, 460800, f4b23293bb2ecf69cc3570853d8c56a1
-0, 2, 2, 1, 460800, 0c03ce2c1c6ec405d7455465ecd559a3
-0, 3, 3, 1, 460800, 7921791695537fba2c3c123da4834cb9
-0, 4, 4, 1, 460800, 30c8e2903a561b84d4cbaf95c668d236
-0, 5, 5, 1, 460800, 7ff42e998217c17592ddf6b584f26cef
-0, 6, 6, 1, 460800, 5e402c48bf097db2d31b82bb4194a382
-0, 7, 7, 1, 460800, 824c49e92c8ae6d99a0207b514dd756c
-0, 8, 8, 1, 460800, 24f189216a1d9cf2313b2d6dbe3dbdd3
-0, 9, 9, 1, 460800, 519179a8e74275d26b183374637e003f
-0, 10, 10, 1, 460800, f18331ddcef0adf5b069bfa98baf8db4
-0, 11, 11, 1, 460800, 081f61688690d47dbdddd5384e5d5a70
-0, 12, 12, 1, 460800, 90dbf019b9035433371a8df41a9268b7
-0, 13, 13, 1, 460800, bb5adfb9c66732898b34186eca1667ba
-0, 14, 14, 1, 460800, cc08cfd64f37783ecddaf143f6ad78bc
-0, 15, 15, 1, 460800, b8ae21d024fe4df903d56f4521993c72
-0, 16, 16, 1, 460800, b45a99907f045dcadf0a2befc11555e3
-0, 17, 17, 1, 460800, 603ba935845e65ab6cccbbec88bbf60d
-0, 18, 18, 1, 460800, df80c8d3e6a77258a306903f17995a18
-0, 19, 19, 1, 460800, 4b7e90c0a5fd0e0cd958d47f0afac636
-0, 20, 20, 1, 460800, 9feb6e36182f1745be6387edea240eb6
-0, 21, 21, 1, 460800, 86e6de4bd0a5ff7558f4cf6c1ec3930d
-0, 22, 22, 1, 460800, 726b69df77edbe7b503d4698656d1320
-0, 23, 23, 1, 460800, d282fb7a953ac205b0a43d00c2d60a33
-0, 24, 24, 1, 460800, eece3daa70cc20208dd75d91ac84c8fd
-0, 25, 25, 1, 460800, c86d23e73bcce351fc315fb1f13348da
-0, 26, 26, 1, 460800, 93497b4f7c5ad9d61212239b7c9d2770
-0, 27, 27, 1, 460800, eb217d2c12de67903835a8c58f620488
-0, 28, 28, 1, 460800, d966480867bb54c8cd044f18388ed486
-0, 29, 29, 1, 460800, 3ea6207942b3181fdd8e8aa6cae1062a
-0, 30, 30, 1, 460800, 2620df54aca086ec0fb9527c6e6f5135
-0, 31, 31, 1, 460800, 43bb7320f0bb583188dc965ddbfade90
-0, 32, 32, 1, 460800, 0cddaa04645f804e02f65b0836412113
-0, 33, 33, 1, 460800, 83b2dc95807289d7f4a4632bf18c2e97
-0, 34, 34, 1, 460800, 98134d0e41e6dd12827049ccf33b4669
-0, 35, 35, 1, 460800, 56f55631731fa39c7acbab0afeb2eb1b
-0, 36, 36, 1, 460800, 379c1105be09d836a515dc909455ddf4
-0, 37, 37, 1, 460800, 1df87c47e9d98731faf1c3885b77e5da
-0, 38, 38, 1, 460800, 9a8734bcbfdb4d97e530683b8b556a26
-0, 39, 39, 1, 460800, c7a7990d0cddc5adfbe27da7a42e025e
-0, 40, 40, 1, 460800, 0c81e46011e03be410feaf056207fd55
-0, 41, 41, 1, 460800, ca76e4e63016ff29d8aeeb9cb053bb6c
-0, 42, 42, 1, 460800, cebfbe299c17c1f8fc1e6b189555c3c2
-0, 43, 43, 1, 460800, 4f002c5feca5e75f07089e0df47507dd
-0, 44, 44, 1, 460800, c5fd83fc4a745abee9b3d9a6eec9dd3e
-0, 45, 45, 1, 460800, 57d9bad9b45aa2746de5d8bdc2c24969
-0, 46, 46, 1, 460800, 9831673ad7dec167af4a959f64258949
-0, 47, 47, 1, 460800, 77a1cb208f70f51bcb01e28d8cba73b4
Test mov-3elist-encrypted failed. Look at tests/data/fate/mov-3elist-encrypted.err for details.
make: *** [fate-mov-3elist-encrypted] Error 1
TEST mov-gpmf-remux
--- ./tests/ref/fate/mov-frag-encrypted 2018-04-18 03:27:04.860164700 +0200
+++ tests/data/fate/mov-frag-encrypted 2018-04-18 03:53:32.984157900 +0200
@@ -31,27 +31,3 @@
0, 21, 21, 1, 9360, e96af3b6c0cc931463ca77d6be0f1148
0, 22, 22, 1, 9360, 04a904d798361959971361401879c7e4
0, 23, 23, 1, 9360, 2f119642340df6d25362b5590ded46b7
-0, 24, 24, 1, 9360, 5993fca2e60050706f857ac76e48f386
-0, 25, 25, 1, 9360, 2ff3b5775fed3d527bfbbeea786787fe
-0, 26, 26, 1, 9360, 42024dbe23d3fb5b0d8987ae1ce390a8
-0, 27, 27, 1, 9360, d804204f0bd9db5f6a758e2c934d9e38
-0, 28, 28, 1, 9360, e322712e6e34c58ec1a2ab5e2c1e3bfe
-0, 29, 29, 1, 9360, 3975bd1a5f6a6b6260276777f9de611e
-0, 30, 30, 1, 9360, 4388f0412efc6310706a7cdedc859ea9
-0, 31, 31, 1, 9360, b4b9a11b0b86635267345a569640e8d4
-0, 32, 32, 1, 9360, 31879c7b8d6b67a4209ffde786bb8cb4
-0, 33, 33, 1, 9360, 4b6dc02d7c889fe4abd4e013b25f585a
-0, 34, 34, 1, 9360, dc73aae82bd39a1220d1106c8d3e8252
-0, 35, 35, 1, 9360, 54c7dfbd49f312806f6c1a89f7c2c36f
-0, 36, 36, 1, 9360, 150abc64f8994d444a521ea90570443c
-0, 37, 37, 1, 9360, d277cdc7dcadbe0016f2e950459e7ebf
-0, 38, 38, 1, 9360, 2196bf338ead90ea54687b85c73c8229
-0, 39, 39, 1, 9360, 53ce5da5365abc0bd3217dd98e7c465d
-0, 40, 40, 1, 9360, 34ee9832aea55c0c4e6f4381c413c10e
-0, 41, 41, 1, 9360, 1769c7b5849e4681119067a06ac29a4f
-0, 42, 42, 1, 9360, 71f53df739ef283a5184c91ef4b158e8
-0, 43, 43, 1, 9360, d2d394739e9a59c06f0354c16843cb63
-0, 44, 44, 1, 9360, d8e458e92ae29344505a24a3059fc584
-0, 45, 45, 1, 9360, 0f1b11a09911851b798df2ef76253a7f
-0, 46, 46, 1, 9360, 5c4a9f22baecf4e749c0d5c65a4f1007
-0, 47, 47, 1, 9360, 3e2b7e7262fdca08d9d1ef6070125c4b
Test mov-frag-encrypted failed. Look at tests/data/fate/mov-frag-encrypted.err for details.
make: *** [fate-mov-frag-encrypted] Error 1
TEST mov-440hz-10ms
TEST mov-ibi-elst-starts-b
TEST mov-elst-ends-betn-b-and-i
--- ./tests/ref/fate/mov-tenc-only-encrypted 2018-04-18 03:27:04.868164700 +0200
+++ tests/data/fate/mov-tenc-only-encrypted 2018-04-18 03:53:32.932157900 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 1024x436
-#sar 0: 1/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 669696, f48f296a85eda5ba069dc851a3228bef
-0, 1, 1, 1, 669696, a50c5f69bfa3387d49b5bdf738e6529c
-0, 2, 2, 1, 669696, 05061299003760f6a4795b408f72aa31
-0, 3, 3, 1, 669696, 2572119f0b0cdd83f8a7e06252cecd3b
-0, 4, 4, 1, 669696, 29fe6a6bdb4a69018e318886a297f07e
-0, 5, 5, 1, 669696, e8233c7fbaecfbff965c7dfdd3982b1b
-0, 6, 6, 1, 669696, d9259df9880ff5d4a4b38282e67f407b
-0, 7, 7, 1, 669696, 3e8d795195038993503ea9ab6984c915
-0, 8, 8, 1, 669696, bc4e2d253b715a34f85aae1b080e3460
-0, 9, 9, 1, 669696, 09aba8b3a96f53f9268e7420a10bfab6
-0, 10, 10, 1, 669696, 179447977dd580da8b35fb5310a809ca
-0, 11, 11, 1, 669696, 7a0eea9d54577990345f5705ab9882be
-0, 12, 12, 1, 669696, 5bb96eb76f461825740e5938456df759
-0, 13, 13, 1, 669696, bd4ac4a760ead774b9422a27dc071964
-0, 14, 14, 1, 669696, 1cc05f760a9b751fc89e77f2bcc97259
-0, 15, 15, 1, 669696, 825d0dee6f0174ba7102892c7de30b4d
-0, 16, 16, 1, 669696, d26a2ef5267f6bb03c4e1d8514eee0df
-0, 17, 17, 1, 669696, c916ffdeadca76596a8f7fd47914b5ef
-0, 18, 18, 1, 669696, 6e085acfa7fee0658ea0ae6188274c17
-0, 19, 19, 1, 669696, 1e95fa5b3561283f05bf0bd44cb91721
-0, 20, 20, 1, 669696, 37e3d135aba9dfb8b87e441753115374
-0, 21, 21, 1, 669696, 9c398310e8564491de624393c16265ce
-0, 22, 22, 1, 669696, c87209e4d2617bc2ab40a75f455f09da
-0, 23, 23, 1, 669696, 2679c2f8d1d1af21982e245945c1ee60
-0, 24, 24, 1, 669696, 6151ab4781f31c5beb66b356ad547122
-0, 25, 25, 1, 669696, f7ef6293bfb3a6a329061cb6a5ed5a38
-0, 26, 26, 1, 669696, 2f6e666d14dfc407ca0c0f347b13eb08
-0, 27, 27, 1, 669696, 3454fa1730d79b1aa8dbbc865dc150f4
-0, 28, 28, 1, 669696, e93dc683e2453419a0419ab9af0f8f95
-0, 29, 29, 1, 669696, 031eb3154f7f83cf86d42bee66be9cf7
-0, 30, 30, 1, 669696, 1205c36723e88811206c68892d3aaed6
-0, 31, 31, 1, 669696, 7dd7a8a19dcd73b31ddc6a6d0c597a42
-0, 32, 32, 1, 669696, 7c91115368ea2531262a1197468bc3f4
-0, 33, 33, 1, 669696, 3cf6d9ba385e0fff76da33299ed5380c
-0, 34, 34, 1, 669696, 859fc8c3ef049e3c1175a85fb0a90a3d
-0, 35, 35, 1, 669696, 1d09ce6c7027103d99a4d5799f6e72ab
-0, 36, 36, 1, 669696, 3dcb8357408ac88abd734128d8f5dd6f
-0, 37, 37, 1, 669696, 4dafce137a0a5178f6efaec878e64d36
-0, 38, 38, 1, 669696, 44c478f29a1399ed03275a7357f57d48
-0, 39, 39, 1, 669696, 6e9edaac7414c0e14591ac3d4d0b1ac4
-0, 40, 40, 1, 669696, 522e4aaeea0825da27f631a9e690d654
-0, 41, 41, 1, 669696, 85f2502a718440834c40051d30f8a65e
-0, 42, 42, 1, 669696, ae8816f7bd4645ef1a17ee6d09b4c8d2
-0, 43, 43, 1, 669696, 914b006fa92f1eb3e590245749f6810d
-0, 44, 44, 1, 669696, 9406901542e94c429dff46108782ed69
-0, 45, 45, 1, 669696, 324c13641c39eef5c476023e358c0391
-0, 46, 46, 1, 669696, 4058e886e17c22e4eb9da1dd0d6ad891
-0, 47, 47, 1, 669696, 9edf9cd15eea985b42fd1f5035b1d693
Test mov-tenc-only-encrypted failed. Look at tests/data/fate/mov-tenc-only-encrypted.err for details.
make: *** [fate-mov-tenc-only-encrypted] Error 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I changed the byte order of the scheme in the previous update but
forgot to update it in the decrypt call. I also updated the comment
in the struct to indicate the byte order.

Also, since it may have been forgotten, this adds two files that need
to be uploaded to fate:

https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-frag-encrypted.mp4
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-tenc-only-encrypted.mp4

[Michael Niedermayer]

Post by Jacob Trimble
On Tue, Apr 17, 2018 at 7:11 PM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Jacob Trimble

Post by Jacob Trimble
Ping again. I know this is low priority, but I would like to get
these merged soon.

Ping. Despite being almost 2 months old, these patches still apply
cleanly. Please take a look. These have been in review for almost 3
months.

Ping (going to keep pinging this until someone merges this or tells me
why not). Day after tomorrow this will be in review for 4 months!!!
Also noticed a bug when integrating this, so here is an updated patch.
libavformat/isom.h | 14 +
libavformat/mov.c | 396 ++++++++++++++++++++++++++-------
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
5 files changed, 450 insertions(+), 82 deletions(-)
9f1b7e04bc8001ad9faa59485090189f529cbf24 0001-avformat-mov-Increase-support-for-v7.patch
From 282effab6026341c49a52950cf8ba11afc9dc6aa Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

maybe iam missing something but applying this to master seems to cause
fate to fail
--- ./tests/ref/fate/mov-3elist-encrypted 2018-04-17 14:20:30.560366780 +0200
+++ tests/data/fate/mov-3elist-encrypted 2018-04-18 03:53:32.872157901 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 640x480
-#sar 0: 0/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 460800, 80fbbdec589e15e6c493b44d243f92a9
-0, 1, 1, 1, 460800, f4b23293bb2ecf69cc3570853d8c56a1
-0, 2, 2, 1, 460800, 0c03ce2c1c6ec405d7455465ecd559a3
-0, 3, 3, 1, 460800, 7921791695537fba2c3c123da4834cb9
-0, 4, 4, 1, 460800, 30c8e2903a561b84d4cbaf95c668d236
-0, 5, 5, 1, 460800, 7ff42e998217c17592ddf6b584f26cef
-0, 6, 6, 1, 460800, 5e402c48bf097db2d31b82bb4194a382
-0, 7, 7, 1, 460800, 824c49e92c8ae6d99a0207b514dd756c
-0, 8, 8, 1, 460800, 24f189216a1d9cf2313b2d6dbe3dbdd3
-0, 9, 9, 1, 460800, 519179a8e74275d26b183374637e003f
-0, 10, 10, 1, 460800, f18331ddcef0adf5b069bfa98baf8db4
-0, 11, 11, 1, 460800, 081f61688690d47dbdddd5384e5d5a70
-0, 12, 12, 1, 460800, 90dbf019b9035433371a8df41a9268b7
-0, 13, 13, 1, 460800, bb5adfb9c66732898b34186eca1667ba
-0, 14, 14, 1, 460800, cc08cfd64f37783ecddaf143f6ad78bc
-0, 15, 15, 1, 460800, b8ae21d024fe4df903d56f4521993c72
-0, 16, 16, 1, 460800, b45a99907f045dcadf0a2befc11555e3
-0, 17, 17, 1, 460800, 603ba935845e65ab6cccbbec88bbf60d
-0, 18, 18, 1, 460800, df80c8d3e6a77258a306903f17995a18
-0, 19, 19, 1, 460800, 4b7e90c0a5fd0e0cd958d47f0afac636
-0, 20, 20, 1, 460800, 9feb6e36182f1745be6387edea240eb6
-0, 21, 21, 1, 460800, 86e6de4bd0a5ff7558f4cf6c1ec3930d
-0, 22, 22, 1, 460800, 726b69df77edbe7b503d4698656d1320
-0, 23, 23, 1, 460800, d282fb7a953ac205b0a43d00c2d60a33
-0, 24, 24, 1, 460800, eece3daa70cc20208dd75d91ac84c8fd
-0, 25, 25, 1, 460800, c86d23e73bcce351fc315fb1f13348da
-0, 26, 26, 1, 460800, 93497b4f7c5ad9d61212239b7c9d2770
-0, 27, 27, 1, 460800, eb217d2c12de67903835a8c58f620488
-0, 28, 28, 1, 460800, d966480867bb54c8cd044f18388ed486
-0, 29, 29, 1, 460800, 3ea6207942b3181fdd8e8aa6cae1062a
-0, 30, 30, 1, 460800, 2620df54aca086ec0fb9527c6e6f5135
-0, 31, 31, 1, 460800, 43bb7320f0bb583188dc965ddbfade90
-0, 32, 32, 1, 460800, 0cddaa04645f804e02f65b0836412113
-0, 33, 33, 1, 460800, 83b2dc95807289d7f4a4632bf18c2e97
-0, 34, 34, 1, 460800, 98134d0e41e6dd12827049ccf33b4669
-0, 35, 35, 1, 460800, 56f55631731fa39c7acbab0afeb2eb1b
-0, 36, 36, 1, 460800, 379c1105be09d836a515dc909455ddf4
-0, 37, 37, 1, 460800, 1df87c47e9d98731faf1c3885b77e5da
-0, 38, 38, 1, 460800, 9a8734bcbfdb4d97e530683b8b556a26
-0, 39, 39, 1, 460800, c7a7990d0cddc5adfbe27da7a42e025e
-0, 40, 40, 1, 460800, 0c81e46011e03be410feaf056207fd55
-0, 41, 41, 1, 460800, ca76e4e63016ff29d8aeeb9cb053bb6c
-0, 42, 42, 1, 460800, cebfbe299c17c1f8fc1e6b189555c3c2
-0, 43, 43, 1, 460800, 4f002c5feca5e75f07089e0df47507dd
-0, 44, 44, 1, 460800, c5fd83fc4a745abee9b3d9a6eec9dd3e
-0, 45, 45, 1, 460800, 57d9bad9b45aa2746de5d8bdc2c24969
-0, 46, 46, 1, 460800, 9831673ad7dec167af4a959f64258949
-0, 47, 47, 1, 460800, 77a1cb208f70f51bcb01e28d8cba73b4
Test mov-3elist-encrypted failed. Look at tests/data/fate/mov-3elist-encrypted.err for details.
make: *** [fate-mov-3elist-encrypted] Error 1
TEST mov-gpmf-remux
--- ./tests/ref/fate/mov-frag-encrypted 2018-04-18 03:27:04.860164700 +0200
+++ tests/data/fate/mov-frag-encrypted 2018-04-18 03:53:32.984157900 +0200
@@ -31,27 +31,3 @@
0, 21, 21, 1, 9360, e96af3b6c0cc931463ca77d6be0f1148
0, 22, 22, 1, 9360, 04a904d798361959971361401879c7e4
0, 23, 23, 1, 9360, 2f119642340df6d25362b5590ded46b7
-0, 24, 24, 1, 9360, 5993fca2e60050706f857ac76e48f386
-0, 25, 25, 1, 9360, 2ff3b5775fed3d527bfbbeea786787fe
-0, 26, 26, 1, 9360, 42024dbe23d3fb5b0d8987ae1ce390a8
-0, 27, 27, 1, 9360, d804204f0bd9db5f6a758e2c934d9e38
-0, 28, 28, 1, 9360, e322712e6e34c58ec1a2ab5e2c1e3bfe
-0, 29, 29, 1, 9360, 3975bd1a5f6a6b6260276777f9de611e
-0, 30, 30, 1, 9360, 4388f0412efc6310706a7cdedc859ea9
-0, 31, 31, 1, 9360, b4b9a11b0b86635267345a569640e8d4
-0, 32, 32, 1, 9360, 31879c7b8d6b67a4209ffde786bb8cb4
-0, 33, 33, 1, 9360, 4b6dc02d7c889fe4abd4e013b25f585a
-0, 34, 34, 1, 9360, dc73aae82bd39a1220d1106c8d3e8252
-0, 35, 35, 1, 9360, 54c7dfbd49f312806f6c1a89f7c2c36f
-0, 36, 36, 1, 9360, 150abc64f8994d444a521ea90570443c
-0, 37, 37, 1, 9360, d277cdc7dcadbe0016f2e950459e7ebf
-0, 38, 38, 1, 9360, 2196bf338ead90ea54687b85c73c8229
-0, 39, 39, 1, 9360, 53ce5da5365abc0bd3217dd98e7c465d
-0, 40, 40, 1, 9360, 34ee9832aea55c0c4e6f4381c413c10e
-0, 41, 41, 1, 9360, 1769c7b5849e4681119067a06ac29a4f
-0, 42, 42, 1, 9360, 71f53df739ef283a5184c91ef4b158e8
-0, 43, 43, 1, 9360, d2d394739e9a59c06f0354c16843cb63
-0, 44, 44, 1, 9360, d8e458e92ae29344505a24a3059fc584
-0, 45, 45, 1, 9360, 0f1b11a09911851b798df2ef76253a7f
-0, 46, 46, 1, 9360, 5c4a9f22baecf4e749c0d5c65a4f1007
-0, 47, 47, 1, 9360, 3e2b7e7262fdca08d9d1ef6070125c4b
Test mov-frag-encrypted failed. Look at tests/data/fate/mov-frag-encrypted.err for details.
make: *** [fate-mov-frag-encrypted] Error 1
TEST mov-440hz-10ms
TEST mov-ibi-elst-starts-b
TEST mov-elst-ends-betn-b-and-i
--- ./tests/ref/fate/mov-tenc-only-encrypted 2018-04-18 03:27:04.868164700 +0200
+++ tests/data/fate/mov-tenc-only-encrypted 2018-04-18 03:53:32.932157900 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 1024x436
-#sar 0: 1/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 669696, f48f296a85eda5ba069dc851a3228bef
-0, 1, 1, 1, 669696, a50c5f69bfa3387d49b5bdf738e6529c
-0, 2, 2, 1, 669696, 05061299003760f6a4795b408f72aa31
-0, 3, 3, 1, 669696, 2572119f0b0cdd83f8a7e06252cecd3b
-0, 4, 4, 1, 669696, 29fe6a6bdb4a69018e318886a297f07e
-0, 5, 5, 1, 669696, e8233c7fbaecfbff965c7dfdd3982b1b
-0, 6, 6, 1, 669696, d9259df9880ff5d4a4b38282e67f407b
-0, 7, 7, 1, 669696, 3e8d795195038993503ea9ab6984c915
-0, 8, 8, 1, 669696, bc4e2d253b715a34f85aae1b080e3460
-0, 9, 9, 1, 669696, 09aba8b3a96f53f9268e7420a10bfab6
-0, 10, 10, 1, 669696, 179447977dd580da8b35fb5310a809ca
-0, 11, 11, 1, 669696, 7a0eea9d54577990345f5705ab9882be
-0, 12, 12, 1, 669696, 5bb96eb76f461825740e5938456df759
-0, 13, 13, 1, 669696, bd4ac4a760ead774b9422a27dc071964
-0, 14, 14, 1, 669696, 1cc05f760a9b751fc89e77f2bcc97259
-0, 15, 15, 1, 669696, 825d0dee6f0174ba7102892c7de30b4d
-0, 16, 16, 1, 669696, d26a2ef5267f6bb03c4e1d8514eee0df
-0, 17, 17, 1, 669696, c916ffdeadca76596a8f7fd47914b5ef
-0, 18, 18, 1, 669696, 6e085acfa7fee0658ea0ae6188274c17
-0, 19, 19, 1, 669696, 1e95fa5b3561283f05bf0bd44cb91721
-0, 20, 20, 1, 669696, 37e3d135aba9dfb8b87e441753115374
-0, 21, 21, 1, 669696, 9c398310e8564491de624393c16265ce
-0, 22, 22, 1, 669696, c87209e4d2617bc2ab40a75f455f09da
-0, 23, 23, 1, 669696, 2679c2f8d1d1af21982e245945c1ee60
-0, 24, 24, 1, 669696, 6151ab4781f31c5beb66b356ad547122
-0, 25, 25, 1, 669696, f7ef6293bfb3a6a329061cb6a5ed5a38
-0, 26, 26, 1, 669696, 2f6e666d14dfc407ca0c0f347b13eb08
-0, 27, 27, 1, 669696, 3454fa1730d79b1aa8dbbc865dc150f4
-0, 28, 28, 1, 669696, e93dc683e2453419a0419ab9af0f8f95
-0, 29, 29, 1, 669696, 031eb3154f7f83cf86d42bee66be9cf7
-0, 30, 30, 1, 669696, 1205c36723e88811206c68892d3aaed6
-0, 31, 31, 1, 669696, 7dd7a8a19dcd73b31ddc6a6d0c597a42
-0, 32, 32, 1, 669696, 7c91115368ea2531262a1197468bc3f4
-0, 33, 33, 1, 669696, 3cf6d9ba385e0fff76da33299ed5380c
-0, 34, 34, 1, 669696, 859fc8c3ef049e3c1175a85fb0a90a3d
-0, 35, 35, 1, 669696, 1d09ce6c7027103d99a4d5799f6e72ab
-0, 36, 36, 1, 669696, 3dcb8357408ac88abd734128d8f5dd6f
-0, 37, 37, 1, 669696, 4dafce137a0a5178f6efaec878e64d36
-0, 38, 38, 1, 669696, 44c478f29a1399ed03275a7357f57d48
-0, 39, 39, 1, 669696, 6e9edaac7414c0e14591ac3d4d0b1ac4
-0, 40, 40, 1, 669696, 522e4aaeea0825da27f631a9e690d654
-0, 41, 41, 1, 669696, 85f2502a718440834c40051d30f8a65e
-0, 42, 42, 1, 669696, ae8816f7bd4645ef1a17ee6d09b4c8d2
-0, 43, 43, 1, 669696, 914b006fa92f1eb3e590245749f6810d
-0, 44, 44, 1, 669696, 9406901542e94c429dff46108782ed69
-0, 45, 45, 1, 669696, 324c13641c39eef5c476023e358c0391
-0, 46, 46, 1, 669696, 4058e886e17c22e4eb9da1dd0d6ad891
-0, 47, 47, 1, 669696, 9edf9cd15eea985b42fd1f5035b1d693
Test mov-tenc-only-encrypted failed. Look at tests/data/fate/mov-tenc-only-encrypted.err for details.
make: *** [fate-mov-tenc-only-encrypted] Error 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I changed the byte order of the scheme in the previous update but
forgot to update it in the decrypt call. I also updated the comment
in the struct to indicate the byte order.
Also, since it may have been forgotten, this adds two files that need
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-frag-encrypted.mp4
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-tenc-only-encrypted.mp4
libavformat/isom.h | 14 +
libavformat/mov.c | 396 ++++++++++++++++++++++++++-------
libavutil/encryption_info.h | 2
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
6 files changed, 451 insertions(+), 83 deletions(-)
cf147ac4d283ac7c6ba8699f984dd3863c3dd3e6 0001-avformat-mov-Increase-support-for-v8.patch
From d30810e7f922a95c5a98337c59295c0894255b5e Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

will apply

thanks

[...]

[James Almer]

Post by Michael Niedermayer

Post by Jacob Trimble
On Tue, Apr 17, 2018 at 7:11 PM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Jacob Trimble

Post by Jacob Trimble
Ping again. I know this is low priority, but I would like to get
these merged soon.

Ping. Despite being almost 2 months old, these patches still apply
cleanly. Please take a look. These have been in review for almost 3
months.

Ping (going to keep pinging this until someone merges this or tells me
why not). Day after tomorrow this will be in review for 4 months!!!
Also noticed a bug when integrating this, so here is an updated patch.
libavformat/isom.h | 14 +
libavformat/mov.c | 396 ++++++++++++++++++++++++++-------
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
5 files changed, 450 insertions(+), 82 deletions(-)
9f1b7e04bc8001ad9faa59485090189f529cbf24 0001-avformat-mov-Increase-support-for-v7.patch
From 282effab6026341c49a52950cf8ba11afc9dc6aa Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

maybe iam missing something but applying this to master seems to cause
fate to fail
--- ./tests/ref/fate/mov-3elist-encrypted 2018-04-17 14:20:30.560366780 +0200
+++ tests/data/fate/mov-3elist-encrypted 2018-04-18 03:53:32.872157901 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 640x480
-#sar 0: 0/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 460800, 80fbbdec589e15e6c493b44d243f92a9
-0, 1, 1, 1, 460800, f4b23293bb2ecf69cc3570853d8c56a1
-0, 2, 2, 1, 460800, 0c03ce2c1c6ec405d7455465ecd559a3
-0, 3, 3, 1, 460800, 7921791695537fba2c3c123da4834cb9
-0, 4, 4, 1, 460800, 30c8e2903a561b84d4cbaf95c668d236
-0, 5, 5, 1, 460800, 7ff42e998217c17592ddf6b584f26cef
-0, 6, 6, 1, 460800, 5e402c48bf097db2d31b82bb4194a382
-0, 7, 7, 1, 460800, 824c49e92c8ae6d99a0207b514dd756c
-0, 8, 8, 1, 460800, 24f189216a1d9cf2313b2d6dbe3dbdd3
-0, 9, 9, 1, 460800, 519179a8e74275d26b183374637e003f
-0, 10, 10, 1, 460800, f18331ddcef0adf5b069bfa98baf8db4
-0, 11, 11, 1, 460800, 081f61688690d47dbdddd5384e5d5a70
-0, 12, 12, 1, 460800, 90dbf019b9035433371a8df41a9268b7
-0, 13, 13, 1, 460800, bb5adfb9c66732898b34186eca1667ba
-0, 14, 14, 1, 460800, cc08cfd64f37783ecddaf143f6ad78bc
-0, 15, 15, 1, 460800, b8ae21d024fe4df903d56f4521993c72
-0, 16, 16, 1, 460800, b45a99907f045dcadf0a2befc11555e3
-0, 17, 17, 1, 460800, 603ba935845e65ab6cccbbec88bbf60d
-0, 18, 18, 1, 460800, df80c8d3e6a77258a306903f17995a18
-0, 19, 19, 1, 460800, 4b7e90c0a5fd0e0cd958d47f0afac636
-0, 20, 20, 1, 460800, 9feb6e36182f1745be6387edea240eb6
-0, 21, 21, 1, 460800, 86e6de4bd0a5ff7558f4cf6c1ec3930d
-0, 22, 22, 1, 460800, 726b69df77edbe7b503d4698656d1320
-0, 23, 23, 1, 460800, d282fb7a953ac205b0a43d00c2d60a33
-0, 24, 24, 1, 460800, eece3daa70cc20208dd75d91ac84c8fd
-0, 25, 25, 1, 460800, c86d23e73bcce351fc315fb1f13348da
-0, 26, 26, 1, 460800, 93497b4f7c5ad9d61212239b7c9d2770
-0, 27, 27, 1, 460800, eb217d2c12de67903835a8c58f620488
-0, 28, 28, 1, 460800, d966480867bb54c8cd044f18388ed486
-0, 29, 29, 1, 460800, 3ea6207942b3181fdd8e8aa6cae1062a
-0, 30, 30, 1, 460800, 2620df54aca086ec0fb9527c6e6f5135
-0, 31, 31, 1, 460800, 43bb7320f0bb583188dc965ddbfade90
-0, 32, 32, 1, 460800, 0cddaa04645f804e02f65b0836412113
-0, 33, 33, 1, 460800, 83b2dc95807289d7f4a4632bf18c2e97
-0, 34, 34, 1, 460800, 98134d0e41e6dd12827049ccf33b4669
-0, 35, 35, 1, 460800, 56f55631731fa39c7acbab0afeb2eb1b
-0, 36, 36, 1, 460800, 379c1105be09d836a515dc909455ddf4
-0, 37, 37, 1, 460800, 1df87c47e9d98731faf1c3885b77e5da
-0, 38, 38, 1, 460800, 9a8734bcbfdb4d97e530683b8b556a26
-0, 39, 39, 1, 460800, c7a7990d0cddc5adfbe27da7a42e025e
-0, 40, 40, 1, 460800, 0c81e46011e03be410feaf056207fd55
-0, 41, 41, 1, 460800, ca76e4e63016ff29d8aeeb9cb053bb6c
-0, 42, 42, 1, 460800, cebfbe299c17c1f8fc1e6b189555c3c2
-0, 43, 43, 1, 460800, 4f002c5feca5e75f07089e0df47507dd
-0, 44, 44, 1, 460800, c5fd83fc4a745abee9b3d9a6eec9dd3e
-0, 45, 45, 1, 460800, 57d9bad9b45aa2746de5d8bdc2c24969
-0, 46, 46, 1, 460800, 9831673ad7dec167af4a959f64258949
-0, 47, 47, 1, 460800, 77a1cb208f70f51bcb01e28d8cba73b4
Test mov-3elist-encrypted failed. Look at tests/data/fate/mov-3elist-encrypted.err for details.
make: *** [fate-mov-3elist-encrypted] Error 1
TEST mov-gpmf-remux
--- ./tests/ref/fate/mov-frag-encrypted 2018-04-18 03:27:04.860164700 +0200
+++ tests/data/fate/mov-frag-encrypted 2018-04-18 03:53:32.984157900 +0200
@@ -31,27 +31,3 @@
0, 21, 21, 1, 9360, e96af3b6c0cc931463ca77d6be0f1148
0, 22, 22, 1, 9360, 04a904d798361959971361401879c7e4
0, 23, 23, 1, 9360, 2f119642340df6d25362b5590ded46b7
-0, 24, 24, 1, 9360, 5993fca2e60050706f857ac76e48f386
-0, 25, 25, 1, 9360, 2ff3b5775fed3d527bfbbeea786787fe
-0, 26, 26, 1, 9360, 42024dbe23d3fb5b0d8987ae1ce390a8
-0, 27, 27, 1, 9360, d804204f0bd9db5f6a758e2c934d9e38
-0, 28, 28, 1, 9360, e322712e6e34c58ec1a2ab5e2c1e3bfe
-0, 29, 29, 1, 9360, 3975bd1a5f6a6b6260276777f9de611e
-0, 30, 30, 1, 9360, 4388f0412efc6310706a7cdedc859ea9
-0, 31, 31, 1, 9360, b4b9a11b0b86635267345a569640e8d4
-0, 32, 32, 1, 9360, 31879c7b8d6b67a4209ffde786bb8cb4
-0, 33, 33, 1, 9360, 4b6dc02d7c889fe4abd4e013b25f585a
-0, 34, 34, 1, 9360, dc73aae82bd39a1220d1106c8d3e8252
-0, 35, 35, 1, 9360, 54c7dfbd49f312806f6c1a89f7c2c36f
-0, 36, 36, 1, 9360, 150abc64f8994d444a521ea90570443c
-0, 37, 37, 1, 9360, d277cdc7dcadbe0016f2e950459e7ebf
-0, 38, 38, 1, 9360, 2196bf338ead90ea54687b85c73c8229
-0, 39, 39, 1, 9360, 53ce5da5365abc0bd3217dd98e7c465d
-0, 40, 40, 1, 9360, 34ee9832aea55c0c4e6f4381c413c10e
-0, 41, 41, 1, 9360, 1769c7b5849e4681119067a06ac29a4f
-0, 42, 42, 1, 9360, 71f53df739ef283a5184c91ef4b158e8
-0, 43, 43, 1, 9360, d2d394739e9a59c06f0354c16843cb63
-0, 44, 44, 1, 9360, d8e458e92ae29344505a24a3059fc584
-0, 45, 45, 1, 9360, 0f1b11a09911851b798df2ef76253a7f
-0, 46, 46, 1, 9360, 5c4a9f22baecf4e749c0d5c65a4f1007
-0, 47, 47, 1, 9360, 3e2b7e7262fdca08d9d1ef6070125c4b
Test mov-frag-encrypted failed. Look at tests/data/fate/mov-frag-encrypted.err for details.
make: *** [fate-mov-frag-encrypted] Error 1
TEST mov-440hz-10ms
TEST mov-ibi-elst-starts-b
TEST mov-elst-ends-betn-b-and-i
--- ./tests/ref/fate/mov-tenc-only-encrypted 2018-04-18 03:27:04.868164700 +0200
+++ tests/data/fate/mov-tenc-only-encrypted 2018-04-18 03:53:32.932157900 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 1024x436
-#sar 0: 1/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 669696, f48f296a85eda5ba069dc851a3228bef
-0, 1, 1, 1, 669696, a50c5f69bfa3387d49b5bdf738e6529c
-0, 2, 2, 1, 669696, 05061299003760f6a4795b408f72aa31
-0, 3, 3, 1, 669696, 2572119f0b0cdd83f8a7e06252cecd3b
-0, 4, 4, 1, 669696, 29fe6a6bdb4a69018e318886a297f07e
-0, 5, 5, 1, 669696, e8233c7fbaecfbff965c7dfdd3982b1b
-0, 6, 6, 1, 669696, d9259df9880ff5d4a4b38282e67f407b
-0, 7, 7, 1, 669696, 3e8d795195038993503ea9ab6984c915
-0, 8, 8, 1, 669696, bc4e2d253b715a34f85aae1b080e3460
-0, 9, 9, 1, 669696, 09aba8b3a96f53f9268e7420a10bfab6
-0, 10, 10, 1, 669696, 179447977dd580da8b35fb5310a809ca
-0, 11, 11, 1, 669696, 7a0eea9d54577990345f5705ab9882be
-0, 12, 12, 1, 669696, 5bb96eb76f461825740e5938456df759
-0, 13, 13, 1, 669696, bd4ac4a760ead774b9422a27dc071964
-0, 14, 14, 1, 669696, 1cc05f760a9b751fc89e77f2bcc97259
-0, 15, 15, 1, 669696, 825d0dee6f0174ba7102892c7de30b4d
-0, 16, 16, 1, 669696, d26a2ef5267f6bb03c4e1d8514eee0df
-0, 17, 17, 1, 669696, c916ffdeadca76596a8f7fd47914b5ef
-0, 18, 18, 1, 669696, 6e085acfa7fee0658ea0ae6188274c17
-0, 19, 19, 1, 669696, 1e95fa5b3561283f05bf0bd44cb91721
-0, 20, 20, 1, 669696, 37e3d135aba9dfb8b87e441753115374
-0, 21, 21, 1, 669696, 9c398310e8564491de624393c16265ce
-0, 22, 22, 1, 669696, c87209e4d2617bc2ab40a75f455f09da
-0, 23, 23, 1, 669696, 2679c2f8d1d1af21982e245945c1ee60
-0, 24, 24, 1, 669696, 6151ab4781f31c5beb66b356ad547122
-0, 25, 25, 1, 669696, f7ef6293bfb3a6a329061cb6a5ed5a38
-0, 26, 26, 1, 669696, 2f6e666d14dfc407ca0c0f347b13eb08
-0, 27, 27, 1, 669696, 3454fa1730d79b1aa8dbbc865dc150f4
-0, 28, 28, 1, 669696, e93dc683e2453419a0419ab9af0f8f95
-0, 29, 29, 1, 669696, 031eb3154f7f83cf86d42bee66be9cf7
-0, 30, 30, 1, 669696, 1205c36723e88811206c68892d3aaed6
-0, 31, 31, 1, 669696, 7dd7a8a19dcd73b31ddc6a6d0c597a42
-0, 32, 32, 1, 669696, 7c91115368ea2531262a1197468bc3f4
-0, 33, 33, 1, 669696, 3cf6d9ba385e0fff76da33299ed5380c
-0, 34, 34, 1, 669696, 859fc8c3ef049e3c1175a85fb0a90a3d
-0, 35, 35, 1, 669696, 1d09ce6c7027103d99a4d5799f6e72ab
-0, 36, 36, 1, 669696, 3dcb8357408ac88abd734128d8f5dd6f
-0, 37, 37, 1, 669696, 4dafce137a0a5178f6efaec878e64d36
-0, 38, 38, 1, 669696, 44c478f29a1399ed03275a7357f57d48
-0, 39, 39, 1, 669696, 6e9edaac7414c0e14591ac3d4d0b1ac4
-0, 40, 40, 1, 669696, 522e4aaeea0825da27f631a9e690d654
-0, 41, 41, 1, 669696, 85f2502a718440834c40051d30f8a65e
-0, 42, 42, 1, 669696, ae8816f7bd4645ef1a17ee6d09b4c8d2
-0, 43, 43, 1, 669696, 914b006fa92f1eb3e590245749f6810d
-0, 44, 44, 1, 669696, 9406901542e94c429dff46108782ed69
-0, 45, 45, 1, 669696, 324c13641c39eef5c476023e358c0391
-0, 46, 46, 1, 669696, 4058e886e17c22e4eb9da1dd0d6ad891
-0, 47, 47, 1, 669696, 9edf9cd15eea985b42fd1f5035b1d693
Test mov-tenc-only-encrypted failed. Look at tests/data/fate/mov-tenc-only-encrypted.err for details.
make: *** [fate-mov-tenc-only-encrypted] Error 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I changed the byte order of the scheme in the previous update but
forgot to update it in the decrypt call. I also updated the comment
in the struct to indicate the byte order.
Also, since it may have been forgotten, this adds two files that need
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-frag-encrypted.mp4
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-tenc-only-encrypted.mp4
libavformat/isom.h | 14 +
libavformat/mov.c | 396 ++++++++++++++++++++++++++-------
libavutil/encryption_info.h | 2
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
6 files changed, 451 insertions(+), 83 deletions(-)
cf147ac4d283ac7c6ba8699f984dd3863c3dd3e6 0001-avformat-mov-Increase-support-for-v8.patch
From d30810e7f922a95c5a98337c59295c0894255b5e Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

will apply
thanks

This seems to leak
http://fate.ffmpeg.org/report.cgi?time=20180419065131&slot=x86_64-archlinux-gcc-valgrind

One of the new tests, and an old test.

[Jacob Trimble]

Post by James Almer

Post by Michael Niedermayer

Post by Jacob Trimble
On Tue, Apr 17, 2018 at 7:11 PM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Jacob Trimble

Post by Jacob Trimble
Ping again. I know this is low priority, but I would like to get
these merged soon.

Ping. Despite being almost 2 months old, these patches still apply
cleanly. Please take a look. These have been in review for almost 3
months.

Ping (going to keep pinging this until someone merges this or tells me
why not). Day after tomorrow this will be in review for 4 months!!!
Also noticed a bug when integrating this, so here is an updated patch.
libavformat/isom.h | 14 +
libavformat/mov.c | 396 ++++++++++++++++++++++++++-------
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
5 files changed, 450 insertions(+), 82 deletions(-)
9f1b7e04bc8001ad9faa59485090189f529cbf24 0001-avformat-mov-Increase-support-for-v7.patch
From 282effab6026341c49a52950cf8ba11afc9dc6aa Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

maybe iam missing something but applying this to master seems to cause
fate to fail
--- ./tests/ref/fate/mov-3elist-encrypted 2018-04-17 14:20:30.560366780 +0200
+++ tests/data/fate/mov-3elist-encrypted 2018-04-18 03:53:32.872157901 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 640x480
-#sar 0: 0/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 460800, 80fbbdec589e15e6c493b44d243f92a9
-0, 1, 1, 1, 460800, f4b23293bb2ecf69cc3570853d8c56a1
-0, 2, 2, 1, 460800, 0c03ce2c1c6ec405d7455465ecd559a3
-0, 3, 3, 1, 460800, 7921791695537fba2c3c123da4834cb9
-0, 4, 4, 1, 460800, 30c8e2903a561b84d4cbaf95c668d236
-0, 5, 5, 1, 460800, 7ff42e998217c17592ddf6b584f26cef
-0, 6, 6, 1, 460800, 5e402c48bf097db2d31b82bb4194a382
-0, 7, 7, 1, 460800, 824c49e92c8ae6d99a0207b514dd756c
-0, 8, 8, 1, 460800, 24f189216a1d9cf2313b2d6dbe3dbdd3
-0, 9, 9, 1, 460800, 519179a8e74275d26b183374637e003f
-0, 10, 10, 1, 460800, f18331ddcef0adf5b069bfa98baf8db4
-0, 11, 11, 1, 460800, 081f61688690d47dbdddd5384e5d5a70
-0, 12, 12, 1, 460800, 90dbf019b9035433371a8df41a9268b7
-0, 13, 13, 1, 460800, bb5adfb9c66732898b34186eca1667ba
-0, 14, 14, 1, 460800, cc08cfd64f37783ecddaf143f6ad78bc
-0, 15, 15, 1, 460800, b8ae21d024fe4df903d56f4521993c72
-0, 16, 16, 1, 460800, b45a99907f045dcadf0a2befc11555e3
-0, 17, 17, 1, 460800, 603ba935845e65ab6cccbbec88bbf60d
-0, 18, 18, 1, 460800, df80c8d3e6a77258a306903f17995a18
-0, 19, 19, 1, 460800, 4b7e90c0a5fd0e0cd958d47f0afac636
-0, 20, 20, 1, 460800, 9feb6e36182f1745be6387edea240eb6
-0, 21, 21, 1, 460800, 86e6de4bd0a5ff7558f4cf6c1ec3930d
-0, 22, 22, 1, 460800, 726b69df77edbe7b503d4698656d1320
-0, 23, 23, 1, 460800, d282fb7a953ac205b0a43d00c2d60a33
-0, 24, 24, 1, 460800, eece3daa70cc20208dd75d91ac84c8fd
-0, 25, 25, 1, 460800, c86d23e73bcce351fc315fb1f13348da
-0, 26, 26, 1, 460800, 93497b4f7c5ad9d61212239b7c9d2770
-0, 27, 27, 1, 460800, eb217d2c12de67903835a8c58f620488
-0, 28, 28, 1, 460800, d966480867bb54c8cd044f18388ed486
-0, 29, 29, 1, 460800, 3ea6207942b3181fdd8e8aa6cae1062a
-0, 30, 30, 1, 460800, 2620df54aca086ec0fb9527c6e6f5135
-0, 31, 31, 1, 460800, 43bb7320f0bb583188dc965ddbfade90
-0, 32, 32, 1, 460800, 0cddaa04645f804e02f65b0836412113
-0, 33, 33, 1, 460800, 83b2dc95807289d7f4a4632bf18c2e97
-0, 34, 34, 1, 460800, 98134d0e41e6dd12827049ccf33b4669
-0, 35, 35, 1, 460800, 56f55631731fa39c7acbab0afeb2eb1b
-0, 36, 36, 1, 460800, 379c1105be09d836a515dc909455ddf4
-0, 37, 37, 1, 460800, 1df87c47e9d98731faf1c3885b77e5da
-0, 38, 38, 1, 460800, 9a8734bcbfdb4d97e530683b8b556a26
-0, 39, 39, 1, 460800, c7a7990d0cddc5adfbe27da7a42e025e
-0, 40, 40, 1, 460800, 0c81e46011e03be410feaf056207fd55
-0, 41, 41, 1, 460800, ca76e4e63016ff29d8aeeb9cb053bb6c
-0, 42, 42, 1, 460800, cebfbe299c17c1f8fc1e6b189555c3c2
-0, 43, 43, 1, 460800, 4f002c5feca5e75f07089e0df47507dd
-0, 44, 44, 1, 460800, c5fd83fc4a745abee9b3d9a6eec9dd3e
-0, 45, 45, 1, 460800, 57d9bad9b45aa2746de5d8bdc2c24969
-0, 46, 46, 1, 460800, 9831673ad7dec167af4a959f64258949
-0, 47, 47, 1, 460800, 77a1cb208f70f51bcb01e28d8cba73b4
Test mov-3elist-encrypted failed. Look at tests/data/fate/mov-3elist-encrypted.err for details.
make: *** [fate-mov-3elist-encrypted] Error 1
TEST mov-gpmf-remux
--- ./tests/ref/fate/mov-frag-encrypted 2018-04-18 03:27:04.860164700 +0200
+++ tests/data/fate/mov-frag-encrypted 2018-04-18 03:53:32.984157900 +0200
@@ -31,27 +31,3 @@
0, 21, 21, 1, 9360, e96af3b6c0cc931463ca77d6be0f1148
0, 22, 22, 1, 9360, 04a904d798361959971361401879c7e4
0, 23, 23, 1, 9360, 2f119642340df6d25362b5590ded46b7
-0, 24, 24, 1, 9360, 5993fca2e60050706f857ac76e48f386
-0, 25, 25, 1, 9360, 2ff3b5775fed3d527bfbbeea786787fe
-0, 26, 26, 1, 9360, 42024dbe23d3fb5b0d8987ae1ce390a8
-0, 27, 27, 1, 9360, d804204f0bd9db5f6a758e2c934d9e38
-0, 28, 28, 1, 9360, e322712e6e34c58ec1a2ab5e2c1e3bfe
-0, 29, 29, 1, 9360, 3975bd1a5f6a6b6260276777f9de611e
-0, 30, 30, 1, 9360, 4388f0412efc6310706a7cdedc859ea9
-0, 31, 31, 1, 9360, b4b9a11b0b86635267345a569640e8d4
-0, 32, 32, 1, 9360, 31879c7b8d6b67a4209ffde786bb8cb4
-0, 33, 33, 1, 9360, 4b6dc02d7c889fe4abd4e013b25f585a
-0, 34, 34, 1, 9360, dc73aae82bd39a1220d1106c8d3e8252
-0, 35, 35, 1, 9360, 54c7dfbd49f312806f6c1a89f7c2c36f
-0, 36, 36, 1, 9360, 150abc64f8994d444a521ea90570443c
-0, 37, 37, 1, 9360, d277cdc7dcadbe0016f2e950459e7ebf
-0, 38, 38, 1, 9360, 2196bf338ead90ea54687b85c73c8229
-0, 39, 39, 1, 9360, 53ce5da5365abc0bd3217dd98e7c465d
-0, 40, 40, 1, 9360, 34ee9832aea55c0c4e6f4381c413c10e
-0, 41, 41, 1, 9360, 1769c7b5849e4681119067a06ac29a4f
-0, 42, 42, 1, 9360, 71f53df739ef283a5184c91ef4b158e8
-0, 43, 43, 1, 9360, d2d394739e9a59c06f0354c16843cb63
-0, 44, 44, 1, 9360, d8e458e92ae29344505a24a3059fc584
-0, 45, 45, 1, 9360, 0f1b11a09911851b798df2ef76253a7f
-0, 46, 46, 1, 9360, 5c4a9f22baecf4e749c0d5c65a4f1007
-0, 47, 47, 1, 9360, 3e2b7e7262fdca08d9d1ef6070125c4b
Test mov-frag-encrypted failed. Look at tests/data/fate/mov-frag-encrypted.err for details.
make: *** [fate-mov-frag-encrypted] Error 1
TEST mov-440hz-10ms
TEST mov-ibi-elst-starts-b
TEST mov-elst-ends-betn-b-and-i
--- ./tests/ref/fate/mov-tenc-only-encrypted 2018-04-18 03:27:04.868164700 +0200
+++ tests/data/fate/mov-tenc-only-encrypted 2018-04-18 03:53:32.932157900 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 1024x436
-#sar 0: 1/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 669696, f48f296a85eda5ba069dc851a3228bef
-0, 1, 1, 1, 669696, a50c5f69bfa3387d49b5bdf738e6529c
-0, 2, 2, 1, 669696, 05061299003760f6a4795b408f72aa31
-0, 3, 3, 1, 669696, 2572119f0b0cdd83f8a7e06252cecd3b
-0, 4, 4, 1, 669696, 29fe6a6bdb4a69018e318886a297f07e
-0, 5, 5, 1, 669696, e8233c7fbaecfbff965c7dfdd3982b1b
-0, 6, 6, 1, 669696, d9259df9880ff5d4a4b38282e67f407b
-0, 7, 7, 1, 669696, 3e8d795195038993503ea9ab6984c915
-0, 8, 8, 1, 669696, bc4e2d253b715a34f85aae1b080e3460
-0, 9, 9, 1, 669696, 09aba8b3a96f53f9268e7420a10bfab6
-0, 10, 10, 1, 669696, 179447977dd580da8b35fb5310a809ca
-0, 11, 11, 1, 669696, 7a0eea9d54577990345f5705ab9882be
-0, 12, 12, 1, 669696, 5bb96eb76f461825740e5938456df759
-0, 13, 13, 1, 669696, bd4ac4a760ead774b9422a27dc071964
-0, 14, 14, 1, 669696, 1cc05f760a9b751fc89e77f2bcc97259
-0, 15, 15, 1, 669696, 825d0dee6f0174ba7102892c7de30b4d
-0, 16, 16, 1, 669696, d26a2ef5267f6bb03c4e1d8514eee0df
-0, 17, 17, 1, 669696, c916ffdeadca76596a8f7fd47914b5ef
-0, 18, 18, 1, 669696, 6e085acfa7fee0658ea0ae6188274c17
-0, 19, 19, 1, 669696, 1e95fa5b3561283f05bf0bd44cb91721
-0, 20, 20, 1, 669696, 37e3d135aba9dfb8b87e441753115374
-0, 21, 21, 1, 669696, 9c398310e8564491de624393c16265ce
-0, 22, 22, 1, 669696, c87209e4d2617bc2ab40a75f455f09da
-0, 23, 23, 1, 669696, 2679c2f8d1d1af21982e245945c1ee60
-0, 24, 24, 1, 669696, 6151ab4781f31c5beb66b356ad547122
-0, 25, 25, 1, 669696, f7ef6293bfb3a6a329061cb6a5ed5a38
-0, 26, 26, 1, 669696, 2f6e666d14dfc407ca0c0f347b13eb08
-0, 27, 27, 1, 669696, 3454fa1730d79b1aa8dbbc865dc150f4
-0, 28, 28, 1, 669696, e93dc683e2453419a0419ab9af0f8f95
-0, 29, 29, 1, 669696, 031eb3154f7f83cf86d42bee66be9cf7
-0, 30, 30, 1, 669696, 1205c36723e88811206c68892d3aaed6
-0, 31, 31, 1, 669696, 7dd7a8a19dcd73b31ddc6a6d0c597a42
-0, 32, 32, 1, 669696, 7c91115368ea2531262a1197468bc3f4
-0, 33, 33, 1, 669696, 3cf6d9ba385e0fff76da33299ed5380c
-0, 34, 34, 1, 669696, 859fc8c3ef049e3c1175a85fb0a90a3d
-0, 35, 35, 1, 669696, 1d09ce6c7027103d99a4d5799f6e72ab
-0, 36, 36, 1, 669696, 3dcb8357408ac88abd734128d8f5dd6f
-0, 37, 37, 1, 669696, 4dafce137a0a5178f6efaec878e64d36
-0, 38, 38, 1, 669696, 44c478f29a1399ed03275a7357f57d48
-0, 39, 39, 1, 669696, 6e9edaac7414c0e14591ac3d4d0b1ac4
-0, 40, 40, 1, 669696, 522e4aaeea0825da27f631a9e690d654
-0, 41, 41, 1, 669696, 85f2502a718440834c40051d30f8a65e
-0, 42, 42, 1, 669696, ae8816f7bd4645ef1a17ee6d09b4c8d2
-0, 43, 43, 1, 669696, 914b006fa92f1eb3e590245749f6810d
-0, 44, 44, 1, 669696, 9406901542e94c429dff46108782ed69
-0, 45, 45, 1, 669696, 324c13641c39eef5c476023e358c0391
-0, 46, 46, 1, 669696, 4058e886e17c22e4eb9da1dd0d6ad891
-0, 47, 47, 1, 669696, 9edf9cd15eea985b42fd1f5035b1d693
Test mov-tenc-only-encrypted failed. Look at tests/data/fate/mov-tenc-only-encrypted.err for details.
make: *** [fate-mov-tenc-only-encrypted] Error 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I changed the byte order of the scheme in the previous update but
forgot to update it in the decrypt call. I also updated the comment
in the struct to indicate the byte order.
Also, since it may have been forgotten, this adds two files that need
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-frag-encrypted.mp4
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-tenc-only-encrypted.mp4
libavformat/isom.h | 14 +
libavformat/mov.c | 396 ++++++++++++++++++++++++++-------
libavutil/encryption_info.h | 2
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
6 files changed, 451 insertions(+), 83 deletions(-)
cf147ac4d283ac7c6ba8699f984dd3863c3dd3e6 0001-avformat-mov-Increase-support-for-v8.patch
From d30810e7f922a95c5a98337c59295c0894255b5e Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

will apply
thanks

There were actually two patches with this email. You wanted me to
split up removing the old methods so the diff was easier to read.
I've attached the patch again. Would you prefer sending it as a
separate email thread?

Post by James Almer
This seems to leak
http://fate.ffmpeg.org/report.cgi?time=20180419065131&slot=x86_64-archlinux-gcc-valgrind
One of the new tests, and an old test.

Sent new patch to fix.

Post by James Almer
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Michael Niedermayer]

Post by Jacob Trimble

Post by Michael Niedermayer

Post by Jacob Trimble
On Tue, Apr 17, 2018 at 7:11 PM, Michael Niedermayer

Post by Michael Niedermayer

Post by Jacob Trimble

Post by Jacob Trimble

Post by Jacob Trimble
Ping again. I know this is low priority, but I would like to get
these merged soon.

Ping. Despite being almost 2 months old, these patches still apply
cleanly. Please take a look. These have been in review for almost 3
months.

Ping (going to keep pinging this until someone merges this or tells me
why not). Day after tomorrow this will be in review for 4 months!!!
Also noticed a bug when integrating this, so here is an updated patch.
libavformat/isom.h | 14 +
libavformat/mov.c | 396 ++++++++++++++++++++++++++-------
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
5 files changed, 450 insertions(+), 82 deletions(-)
9f1b7e04bc8001ad9faa59485090189f529cbf24 0001-avformat-mov-Increase-support-for-v7.patch
From 282effab6026341c49a52950cf8ba11afc9dc6aa Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

maybe iam missing something but applying this to master seems to cause
fate to fail
--- ./tests/ref/fate/mov-3elist-encrypted 2018-04-17 14:20:30.560366780 +0200
+++ tests/data/fate/mov-3elist-encrypted 2018-04-18 03:53:32.872157901 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 640x480
-#sar 0: 0/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 460800, 80fbbdec589e15e6c493b44d243f92a9
-0, 1, 1, 1, 460800, f4b23293bb2ecf69cc3570853d8c56a1
-0, 2, 2, 1, 460800, 0c03ce2c1c6ec405d7455465ecd559a3
-0, 3, 3, 1, 460800, 7921791695537fba2c3c123da4834cb9
-0, 4, 4, 1, 460800, 30c8e2903a561b84d4cbaf95c668d236
-0, 5, 5, 1, 460800, 7ff42e998217c17592ddf6b584f26cef
-0, 6, 6, 1, 460800, 5e402c48bf097db2d31b82bb4194a382
-0, 7, 7, 1, 460800, 824c49e92c8ae6d99a0207b514dd756c
-0, 8, 8, 1, 460800, 24f189216a1d9cf2313b2d6dbe3dbdd3
-0, 9, 9, 1, 460800, 519179a8e74275d26b183374637e003f
-0, 10, 10, 1, 460800, f18331ddcef0adf5b069bfa98baf8db4
-0, 11, 11, 1, 460800, 081f61688690d47dbdddd5384e5d5a70
-0, 12, 12, 1, 460800, 90dbf019b9035433371a8df41a9268b7
-0, 13, 13, 1, 460800, bb5adfb9c66732898b34186eca1667ba
-0, 14, 14, 1, 460800, cc08cfd64f37783ecddaf143f6ad78bc
-0, 15, 15, 1, 460800, b8ae21d024fe4df903d56f4521993c72
-0, 16, 16, 1, 460800, b45a99907f045dcadf0a2befc11555e3
-0, 17, 17, 1, 460800, 603ba935845e65ab6cccbbec88bbf60d
-0, 18, 18, 1, 460800, df80c8d3e6a77258a306903f17995a18
-0, 19, 19, 1, 460800, 4b7e90c0a5fd0e0cd958d47f0afac636
-0, 20, 20, 1, 460800, 9feb6e36182f1745be6387edea240eb6
-0, 21, 21, 1, 460800, 86e6de4bd0a5ff7558f4cf6c1ec3930d
-0, 22, 22, 1, 460800, 726b69df77edbe7b503d4698656d1320
-0, 23, 23, 1, 460800, d282fb7a953ac205b0a43d00c2d60a33
-0, 24, 24, 1, 460800, eece3daa70cc20208dd75d91ac84c8fd
-0, 25, 25, 1, 460800, c86d23e73bcce351fc315fb1f13348da
-0, 26, 26, 1, 460800, 93497b4f7c5ad9d61212239b7c9d2770
-0, 27, 27, 1, 460800, eb217d2c12de67903835a8c58f620488
-0, 28, 28, 1, 460800, d966480867bb54c8cd044f18388ed486
-0, 29, 29, 1, 460800, 3ea6207942b3181fdd8e8aa6cae1062a
-0, 30, 30, 1, 460800, 2620df54aca086ec0fb9527c6e6f5135
-0, 31, 31, 1, 460800, 43bb7320f0bb583188dc965ddbfade90
-0, 32, 32, 1, 460800, 0cddaa04645f804e02f65b0836412113
-0, 33, 33, 1, 460800, 83b2dc95807289d7f4a4632bf18c2e97
-0, 34, 34, 1, 460800, 98134d0e41e6dd12827049ccf33b4669
-0, 35, 35, 1, 460800, 56f55631731fa39c7acbab0afeb2eb1b
-0, 36, 36, 1, 460800, 379c1105be09d836a515dc909455ddf4
-0, 37, 37, 1, 460800, 1df87c47e9d98731faf1c3885b77e5da
-0, 38, 38, 1, 460800, 9a8734bcbfdb4d97e530683b8b556a26
-0, 39, 39, 1, 460800, c7a7990d0cddc5adfbe27da7a42e025e
-0, 40, 40, 1, 460800, 0c81e46011e03be410feaf056207fd55
-0, 41, 41, 1, 460800, ca76e4e63016ff29d8aeeb9cb053bb6c
-0, 42, 42, 1, 460800, cebfbe299c17c1f8fc1e6b189555c3c2
-0, 43, 43, 1, 460800, 4f002c5feca5e75f07089e0df47507dd
-0, 44, 44, 1, 460800, c5fd83fc4a745abee9b3d9a6eec9dd3e
-0, 45, 45, 1, 460800, 57d9bad9b45aa2746de5d8bdc2c24969
-0, 46, 46, 1, 460800, 9831673ad7dec167af4a959f64258949
-0, 47, 47, 1, 460800, 77a1cb208f70f51bcb01e28d8cba73b4
Test mov-3elist-encrypted failed. Look at tests/data/fate/mov-3elist-encrypted.err for details.
make: *** [fate-mov-3elist-encrypted] Error 1
TEST mov-gpmf-remux
--- ./tests/ref/fate/mov-frag-encrypted 2018-04-18 03:27:04.860164700 +0200
+++ tests/data/fate/mov-frag-encrypted 2018-04-18 03:53:32.984157900 +0200
@@ -31,27 +31,3 @@
0, 21, 21, 1, 9360, e96af3b6c0cc931463ca77d6be0f1148
0, 22, 22, 1, 9360, 04a904d798361959971361401879c7e4
0, 23, 23, 1, 9360, 2f119642340df6d25362b5590ded46b7
-0, 24, 24, 1, 9360, 5993fca2e60050706f857ac76e48f386
-0, 25, 25, 1, 9360, 2ff3b5775fed3d527bfbbeea786787fe
-0, 26, 26, 1, 9360, 42024dbe23d3fb5b0d8987ae1ce390a8
-0, 27, 27, 1, 9360, d804204f0bd9db5f6a758e2c934d9e38
-0, 28, 28, 1, 9360, e322712e6e34c58ec1a2ab5e2c1e3bfe
-0, 29, 29, 1, 9360, 3975bd1a5f6a6b6260276777f9de611e
-0, 30, 30, 1, 9360, 4388f0412efc6310706a7cdedc859ea9
-0, 31, 31, 1, 9360, b4b9a11b0b86635267345a569640e8d4
-0, 32, 32, 1, 9360, 31879c7b8d6b67a4209ffde786bb8cb4
-0, 33, 33, 1, 9360, 4b6dc02d7c889fe4abd4e013b25f585a
-0, 34, 34, 1, 9360, dc73aae82bd39a1220d1106c8d3e8252
-0, 35, 35, 1, 9360, 54c7dfbd49f312806f6c1a89f7c2c36f
-0, 36, 36, 1, 9360, 150abc64f8994d444a521ea90570443c
-0, 37, 37, 1, 9360, d277cdc7dcadbe0016f2e950459e7ebf
-0, 38, 38, 1, 9360, 2196bf338ead90ea54687b85c73c8229
-0, 39, 39, 1, 9360, 53ce5da5365abc0bd3217dd98e7c465d
-0, 40, 40, 1, 9360, 34ee9832aea55c0c4e6f4381c413c10e
-0, 41, 41, 1, 9360, 1769c7b5849e4681119067a06ac29a4f
-0, 42, 42, 1, 9360, 71f53df739ef283a5184c91ef4b158e8
-0, 43, 43, 1, 9360, d2d394739e9a59c06f0354c16843cb63
-0, 44, 44, 1, 9360, d8e458e92ae29344505a24a3059fc584
-0, 45, 45, 1, 9360, 0f1b11a09911851b798df2ef76253a7f
-0, 46, 46, 1, 9360, 5c4a9f22baecf4e749c0d5c65a4f1007
-0, 47, 47, 1, 9360, 3e2b7e7262fdca08d9d1ef6070125c4b
Test mov-frag-encrypted failed. Look at tests/data/fate/mov-frag-encrypted.err for details.
make: *** [fate-mov-frag-encrypted] Error 1
TEST mov-440hz-10ms
TEST mov-ibi-elst-starts-b
TEST mov-elst-ends-betn-b-and-i
--- ./tests/ref/fate/mov-tenc-only-encrypted 2018-04-18 03:27:04.868164700 +0200
+++ tests/data/fate/mov-tenc-only-encrypted 2018-04-18 03:53:32.932157900 +0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 1024x436
-#sar 0: 1/1
-#stream#, dts, pts, duration, size, hash
-0, 0, 0, 1, 669696, f48f296a85eda5ba069dc851a3228bef
-0, 1, 1, 1, 669696, a50c5f69bfa3387d49b5bdf738e6529c
-0, 2, 2, 1, 669696, 05061299003760f6a4795b408f72aa31
-0, 3, 3, 1, 669696, 2572119f0b0cdd83f8a7e06252cecd3b
-0, 4, 4, 1, 669696, 29fe6a6bdb4a69018e318886a297f07e
-0, 5, 5, 1, 669696, e8233c7fbaecfbff965c7dfdd3982b1b
-0, 6, 6, 1, 669696, d9259df9880ff5d4a4b38282e67f407b
-0, 7, 7, 1, 669696, 3e8d795195038993503ea9ab6984c915
-0, 8, 8, 1, 669696, bc4e2d253b715a34f85aae1b080e3460
-0, 9, 9, 1, 669696, 09aba8b3a96f53f9268e7420a10bfab6
-0, 10, 10, 1, 669696, 179447977dd580da8b35fb5310a809ca
-0, 11, 11, 1, 669696, 7a0eea9d54577990345f5705ab9882be
-0, 12, 12, 1, 669696, 5bb96eb76f461825740e5938456df759
-0, 13, 13, 1, 669696, bd4ac4a760ead774b9422a27dc071964
-0, 14, 14, 1, 669696, 1cc05f760a9b751fc89e77f2bcc97259
-0, 15, 15, 1, 669696, 825d0dee6f0174ba7102892c7de30b4d
-0, 16, 16, 1, 669696, d26a2ef5267f6bb03c4e1d8514eee0df
-0, 17, 17, 1, 669696, c916ffdeadca76596a8f7fd47914b5ef
-0, 18, 18, 1, 669696, 6e085acfa7fee0658ea0ae6188274c17
-0, 19, 19, 1, 669696, 1e95fa5b3561283f05bf0bd44cb91721
-0, 20, 20, 1, 669696, 37e3d135aba9dfb8b87e441753115374
-0, 21, 21, 1, 669696, 9c398310e8564491de624393c16265ce
-0, 22, 22, 1, 669696, c87209e4d2617bc2ab40a75f455f09da
-0, 23, 23, 1, 669696, 2679c2f8d1d1af21982e245945c1ee60
-0, 24, 24, 1, 669696, 6151ab4781f31c5beb66b356ad547122
-0, 25, 25, 1, 669696, f7ef6293bfb3a6a329061cb6a5ed5a38
-0, 26, 26, 1, 669696, 2f6e666d14dfc407ca0c0f347b13eb08
-0, 27, 27, 1, 669696, 3454fa1730d79b1aa8dbbc865dc150f4
-0, 28, 28, 1, 669696, e93dc683e2453419a0419ab9af0f8f95
-0, 29, 29, 1, 669696, 031eb3154f7f83cf86d42bee66be9cf7
-0, 30, 30, 1, 669696, 1205c36723e88811206c68892d3aaed6
-0, 31, 31, 1, 669696, 7dd7a8a19dcd73b31ddc6a6d0c597a42
-0, 32, 32, 1, 669696, 7c91115368ea2531262a1197468bc3f4
-0, 33, 33, 1, 669696, 3cf6d9ba385e0fff76da33299ed5380c
-0, 34, 34, 1, 669696, 859fc8c3ef049e3c1175a85fb0a90a3d
-0, 35, 35, 1, 669696, 1d09ce6c7027103d99a4d5799f6e72ab
-0, 36, 36, 1, 669696, 3dcb8357408ac88abd734128d8f5dd6f
-0, 37, 37, 1, 669696, 4dafce137a0a5178f6efaec878e64d36
-0, 38, 38, 1, 669696, 44c478f29a1399ed03275a7357f57d48
-0, 39, 39, 1, 669696, 6e9edaac7414c0e14591ac3d4d0b1ac4
-0, 40, 40, 1, 669696, 522e4aaeea0825da27f631a9e690d654
-0, 41, 41, 1, 669696, 85f2502a718440834c40051d30f8a65e
-0, 42, 42, 1, 669696, ae8816f7bd4645ef1a17ee6d09b4c8d2
-0, 43, 43, 1, 669696, 914b006fa92f1eb3e590245749f6810d
-0, 44, 44, 1, 669696, 9406901542e94c429dff46108782ed69
-0, 45, 45, 1, 669696, 324c13641c39eef5c476023e358c0391
-0, 46, 46, 1, 669696, 4058e886e17c22e4eb9da1dd0d6ad891
-0, 47, 47, 1, 669696, 9edf9cd15eea985b42fd1f5035b1d693
Test mov-tenc-only-encrypted failed. Look at tests/data/fate/mov-tenc-only-encrypted.err for details.
make: *** [fate-mov-tenc-only-encrypted] Error 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I changed the byte order of the scheme in the previous update but
forgot to update it in the decrypt call. I also updated the comment
in the struct to indicate the byte order.
Also, since it may have been forgotten, this adds two files that need
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-frag-encrypted.mp4
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-tenc-only-encrypted.mp4
libavformat/isom.h | 14 +
libavformat/mov.c | 396 ++++++++++++++++++++++++++-------
libavutil/encryption_info.h | 2
tests/fate/mov.mak | 8
tests/ref/fate/mov-frag-encrypted | 57 ++++
tests/ref/fate/mov-tenc-only-encrypted | 57 ++++
6 files changed, 451 insertions(+), 83 deletions(-)
cf147ac4d283ac7c6ba8699f984dd3863c3dd3e6 0001-avformat-mov-Increase-support-for-v8.patch
From d30810e7f922a95c5a98337c59295c0894255b5e Mon Sep 17 00:00:00 2001
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

will apply
thanks

There were actually two patches with this email. You wanted me to
split up removing the old methods so the diff was easier to read.
I've attached the patch again. Would you prefer sending it as a
separate email thread?

I didnt miss it, its locally and should be in my next push


thx

[...]