> > > > + 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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
