On Mon, Mar 24, 2014 at 08:13:49PM +0100, Anton Khirnov wrote:
>
> 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.
Ah, thanks, I undestand now. I'll look into doing what avconv does in mpv too
then.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
