On Mon, 24 Mar 2014 18:31:04 +0100, Alessandro Ghedini <[email protected]> wrote: > On Tue, Mar 18, 2014 at 06:26:47PM +0100, Anton Khirnov wrote: > > @@ -229,8 +238,38 @@ static int filter_frame(AVFilterLink *inlink, AVFrame > > *buf) > > AVFilterLink *outlink = inlink->dst->outputs[0]; > > int nb_samples = buf->nb_samples; > > AVFrame *out_buf; > > + AVFrameSideData *sd = av_frame_get_side_data(buf, > > AV_FRAME_DATA_REPLAYGAIN); > > Now that the patches have been merged, I've been trying to use this filter > with > mpv to play a few mp3s and see if it can be used to replace mpv's af_volume > (which already supports replaygain). > > The problem is, libav's af_volume replaygain support doesn't seem to work at > all > (with my mp3 files anyway), i.e. av_frame_get_side_data() always returns NULL > even if the files do have replaygain tags (and ff_export_replaygain() is > called > without errors in mp3dec.c). > > So, it is my understanding that the AVFrame's replaygain side data used by the > filter is initialized from the AVPacket side data by ff_decode_frame_props(), > so I added a call to that function in decode_frame() in > mpegaudiodec_template.c > but it still doesn't work, because apparently the packet's replaygain side > data > isn't initialized either... then I noticed this comment in the AVStream > definition: > > > * There may be no overlap between the side data in this array and side data > > * in the packets. I.e. a given side data is either exported by the muxer > > * (demuxing) / set by the caller (muxing) in this array, then it never > > * appears in the packets, or the side data is exported / sent through > > * the packets (always in the first packet where the value becomes known or > > * changes), then it does not appear in this array. > > ... > > AVPacketSideData *side_data; > > Which, if I understand it correctly, means that the replaygain data is either > in the stream (put there by ff_replaygain_export() in mp3dec.c) or in the > packets, which in turn means that the av_frame_get_side_data() call in > af_volume > will always return NULL, at least for mp3s, since that information is always > in the AVStream. > > So, is this on purpose (meaning that the replaygain support in af_volume > can't be used with mp3/flac/ogg/...)? Is there any way this could be fixed?
It can be used with mp3, and I have tested that it works with avconv+af_volume before pushing (other formats are not implemented yet). However this comment you quoted is indeed relevant -- we have deliberately decided not to add stream-global data to the packets, to avoid certain kinds of issues. The responsibility for transporting this side data to wherever it is needed then falls on the caller. In avconv, patch 6/9 from this set handles this by adding the stream-global side data to the first packet of the stream. The data then gets automatically transferred from packets to decoded frame by libavcodec and from there travels to lavfi. In mpv, you could do the same. Or you could transfer the stream data directly to decoded frames. Or you could parse the data yourself and configure the volume filter manually. Depends on the use case really -- since I'm not familiar with the code I can't really tell what would be the best. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
