> Some updates: recording video actually works fine in both cases of only > video and video+audio. A mistake in the video router was channeling > audio frames to what should have been the video stream.
I think every instance of this working is because ffmpeg and the media players you tried are good at making educated guesses. The RTP payload format spec for opus is a proposed standard (rfc7587 <https://datatracker.ietf.org/doc/rfc7587/>) and the one for vp8 (rfc7741 <https://datatracker.ietf.org/doc/rfc7741/>) uses a profile of RTP that SDP hasn’t been updated to implement yet. So I’m not sure how ffmpeg parses SDP files or if it uses a library but when you step back and take a look, you haven’t put in any specifics for either codec besides from maybe their names. > v=0 > o=- 0 0 IN IP4 127.0.0.1 > s=- > c=IN IP4 127.0.0.1 > t=0 0 > m=audio 5006 RTP/AVP 109 > a=rtpmap:109 opus/48000/2 > m=video 5004 RTP/AVP 120 > a=rtpmap:120 VP8/90000 You can try reading the rfc’s and filling in the extra codec info it needs, but if you’re the one setting up the session, why not just use a simpler protocol? (I’m assuming the localhost is just a stand-in) > However, the issue persists when trying to record Opus audio; it is just > not possible to play it back, supposedly due to missing headers (but > then how is it possible to record incoming RTP Opus audio?) Like, you told ffmpeg it was going to be 48khz, 2 chs it believed your copy codec and just dumped everything into a file. But when you open up the file, does it really have two channels? is the audio interleaved? Nobody knows. _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
