On Fri, 21 Mar 2014 11:28:54 +0100, Alessandro Ghedini <[email protected]> wrote: > On gio, mar 20, 2014 at 08:11:33 +0100, Anton Khirnov wrote: > > > > On Tue, 18 Mar 2014 19:19:16 +0100, Alessandro Ghedini > > <[email protected]> wrote: > > > On mar, mar 18, 2014 at 06:26:42 +0100, Anton Khirnov wrote: > > > > +int ff_replaygain_export(AVStream *st, AVDictionary *metadata) > > > > +{ > > > > + const AVDictionaryEntry *tg, *tp, *ag, *ap; > > > > + > > > > + tg = av_dict_get(metadata, "REPLAYGAIN_TRACK_GAIN", NULL, 0); > > > > + tp = av_dict_get(metadata, "REPLAYGAIN_TRACK_PEAK", NULL, 0); > > > > + ag = av_dict_get(metadata, "REPLAYGAIN_ALBUM_GAIN", NULL, 0); > > > > + ap = av_dict_get(metadata, "REPLAYGAIN_ALBUM_PEAK", NULL, 0); > > > > + > > > > + return replaygain_export(st, > > > > + tg ? tg->value : NULL, > > > > + tp ? tp->value : NULL, > > > > + ag ? ag->value : NULL, > > > > + ap ? ap->value : NULL); > > > > > > I was wondering if it'd be possible to make this support LAME's XING/Info > > > header as well, or better, make this so that it'd be possible to add > > > support > > > for the XING thing later if one wanted to do so. > > > > > > With the proposed interface the information from the LAME header would > > > need to > > > be added directly to the stream metadata (from mp3dec.c I'd imagine) as > > > REPLAYGAIN_* tags (e.g. if they are not present already), but I'm not > > > sure if > > > that would be acceptable. > > > > No need to go through metadata I think, we could adapt the internal API > > directly > > for this. Shouldn't be very hard to do. > > Ok, so this is what I've come up with: > > * Make replaygain_export() take numbers (int32_t or whatever) directly > * Move the parse_*() calls to ff_replaygain_export() > * Export replaygain_export() in replaygain.h as well. > * Maybe rename ff_replaygain_export() to ff_replaygain_metadata_export()? > * Maybe rename replaygain_export() to ff_replaygain_export()? > > So basically, one would normally still call ff_replaygain_export() for the > "default" metadata parsing, but if custom decoding is needed (like in the case > of LAME), replaygain_export() would be called directly with the values already > decoded, so that the AV_PKT_DATA_REPLAYGAIN creation is not duplicated. > > I'm still not sure what to do in the case where both LAME header and > REPLAYGAIN_* tags are present (not sure if it makes a lot of sense to have > multiple AV_PKT_DATA_REPLAYGAIN, though I guess it wouldn't hurt either). >
It would hurt actually, we do not allow duplicate side data of the same type. The demuxer will just have to pick one (or perhaps make it a private option) -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
