[FFmpeg-devel] Patch to libavc/opus to create extradata if missing

Jonathan Baudanza jon at jonb.org
Mon Dec 28 20:03:02 EET 2020

> Actually its not impossible to create extradata from raw Opus streams.
> The extradata only contains a magic, #channes, padding, a sample rate and
> a channel_family.
> We know the magic, the #channels can be found out via the packet's
> contents and whether it contains multiple packets, the padding would
> be 0 because its a stream, the sample rate is always 48000 (we purpusefully
> disrespect the container's sample rate in case of Opus, which this is),
> and the mapping family can be set to 255 to just let the decoder decide
> on the number of channels.
> > The RTP demuxer should start exporting extradata instead, if possible. Either generated from available stream information, or taken verbatim if present. Not sure how the RTP encapsulation for Opus is defined in this regard.
> >
> Yes, I think that's the best solution. Just follow the steps I described above, and
> to write it out you can check out the opus_write_extradata() function in
> libavcodec/opusenc.c.

Thank you for the feedback everyone. I agree, the RTP demuxer is the best place for this. I will resubmit the patch as such.

I have a question about "purposefully disrespecting the container sample rate". In the case of SDP, it is possible to include the sample rate of the source in the sprop-maxcapturerate parameter in the a=fmtp section. For example (Taken from RFC7587 Section 7): 

       m=audio 54312 RTP/AVP 101
       a=rtpmap:101 opus/48000/2
       a=fmtp:101 maxplaybackrate=16000; sprop-maxcapturerate=16000;
       maxaveragebitrate=20000; stereo=1; useinbandfec=1; usedtx=0

In this case, would it be appropriate to set the sample rate in the opus header to 16000? I think in any case, we are allowed to set it to 0, but if the source sample rate is available we might as well use it.

More information about the ffmpeg-devel mailing list