[FFmpeg-devel] support for reading / writing encrypted MP4 files

[Eran Kornblau]

> > > > +    case MKTAG('e','n','c','v'):        // encrypted video
> > > > +    case MKTAG('e','n','c','a'):        // encrypted audio
> > > > +        id = mov_codec_id(st, format);
> > > > +        st->codec->codec_id = id;
> > > 
> > > this seems missing a check for st->codec->codec_id being "unset"
> > > before setting it
> > > 
> > Will add it
> > 
While testing this change, I found that for audio, at this point codec_id is actually already initialized - 
it gets initialized when ff_mov_read_esds calls ff_mp4_read_dec_config_descr, in this line:
    st->codec->codec_id= ff_codec_get_id(ff_mp4_obj_type, object_type_id);

What happens with my current code is that this outputs a warning that frma is ignored because codec_id
is not none. I think I will just skip the warning when st->codec->codec_id "happens to be" the same as 
the codec that was inferred by the frma atom.
 
This appears to work well:
    case MKTAG('e','n','c','v'):        // encrypted video
    case MKTAG('e','n','c','a'):        // encrypted audio
        id = mov_codec_id(st, format);
        if (st->codec->codec_id != AV_CODEC_ID_NONE &&
            st->codec->codec_id != id) {
            av_log(c->fc, AV_LOG_WARNING,
                   "ignoring 'frma' atom of '%.4s', stream has codec id %d\n",
                   (char*)&format, st->codec->codec_id);
            break;
        }

        st->codec->codec_id = id;
        sc->format = format;
        break;

Please let me know if you think that is ok, and I will resubmit the patch with all fixes.

> > > 
> > > the way these are printed would lead to different results on big and
> > > little endian
> > > 
> > Correct, however it's already done this way in a few other places in this file (search for %.4s)
> > Do you prefer that I will print it with %c%c%c%c as in ff_mov_read_stsd_entries ?
> 
> whatever way you prefer
> 
Ok, so I think I'll just leave it as is - big endian environments will get the atom name in 
reverse order in the log message (I assume 99% of the people use ffmpeg on little endian anyway... :))

Thanks

Eran