On Tue, Dec 29, 2020, at 6:41 AM, Lynne wrote:
Dec 28, 2020, 19:03 by jon@jonb.org:
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.
Thank you for all the feedback everyone. I've updated the patch to build the opus header inside of ff_rtp_parse_open in libavformat/rtpdec.c. I set the mapping_family to 0, since I believe Opus/RTP only supports 2 channels. I set the input sample rate to 0, which the spec considers "unspecified". Let me know what you think of this approach for these values. Happy to switch them to 255/48000 if you prefer. I copied the bytestream code from opusenc.c. There's now 3 or 4 different places in the codebase where opus headers are getting built. Let me know if you'd like me to refactor this a bit. I didn't want to touch too many components with my first patch.