[FFmpeg-devel] [PATCH] ogg: discard vorbis metadata from extradata
Måns Rullgård
mans
Mon Jan 31 19:30:02 CET 2011
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> On Mon, Jan 31, 2011 at 01:19:41PM +0000, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> > On Fri, Jan 21, 2011 at 06:34:16PM +0000, M?ns Rullg?rd wrote:
>> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> >> >> > + if (pkt_type != 3) {
>> >> >> > priv->len[pkt_type >> 1] = os->psize;
>> >> >> > priv->packet[pkt_type >> 1] = av_mallocz(os->psize);
>> >> >> > memcpy(priv->packet[pkt_type >> 1], os->buf + os->pstart, os->psize);
>> >> >> > + }
>> >> >>
>> >> >> IIRC there are apps which expect to find the metadata header in the
>> >> >> extradata in order to send it to libvorbis (which _insists_ on having
>> >> >> it). This will break such apps unless a dummy metadata header is
>> >> >> inserted here instead.
>> >> >
>> >> > Hard to implement that without having such an application at hand.
>> >>
>> >> I don't see why.
>> >
>> > Because developing without testing doesn't work. However MPlayer can do this
>> > if you force it.
>> >
>> >> > Also I thought that libvorbis wouldn't accept this extradata format
>> >> > directly anyway, so such applications already have to rewrite this
>> >> > so it is not that much effort for them to add
>> >>
>> >> Vorbis in matroska uses the same extradata format. How do apps handle
>> >> that wrt metadata?
>> >
>> > They convert it back to the original format and call the headerin function.
>> > Anyway below a patch that discards all except for the part that libvorbis
>> > requires.
>> > Which happens to fit quite well since we do not actually parse that part into
>> > metadata and I guess it was intended to allow workarounds for encoder bugs
>> > on the decoder side.
>> >
>> > diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
>> > index cdb0266..bf0b4bb 100644
>> > --- a/libavformat/oggparsevorbis.c
>> > +++ b/libavformat/oggparsevorbis.c
>> > @@ -252,8 +252,16 @@ vorbis_header (AVFormatContext * s, int idx)
>> > st->time_base.num = 1;
>> > st->time_base.den = st->codec->sample_rate;
>> > } else if (os->buf[os->pstart] == 3) {
>> > - if (os->psize > 8)
>> > - ff_vorbis_comment (s, &st->metadata, os->buf + os->pstart + 7, os->psize - 8);
>> > + if (os->psize > 8 &&
>> > + ff_vorbis_comment(s, &st->metadata, os->buf + os->pstart + 7, os->psize - 8) >= 0) {
>> > + // drop all metadata we parsed and which is not required by libvorbis
>> > + unsigned new_len = 7 + 4 + AV_RL32(priv->packet[1] + 7) + 4 + 1;
>> > + if (new_len >= 16 && new_len < os->psize) {
>> > + AV_WL32(priv->packet[1] + new_len - 5, 0);
>> > + priv->packet[1][new_len - 1] = 1;
>> > + priv->len[1] = new_len;
>>
>> Shouldn't there be a realloc here? Otherwise there's not much point
>> in doing this at all.
>
> What would be the point of a realloc besides wasting CPU time?
> The point is that priv->len is smaller and thus the amount
> of data that is copied into extradata is smaller.
> I can't imagine we have to optimize for a few 100 kB during header
> parsing.
You're right of course. I overlooked the second copying. Please send
a properly formatted patch and we'll apply it.
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-devel
mailing list