[Libav-user] Decoding RTP streams with in-band SDP
ereichert at trafficland.com
Fri Sep 16 15:24:59 EEST 2016
On 9/16/16, 8:03 AM, "Libav-user on behalf of Carl Eugen Hoyos" <libav-user-bounces at ffmpeg.org on behalf of ceffmpeg at gmail.com> wrote:
2016-09-16 2:12 GMT+02:00 Eric Reichert <ereichert at trafficland.com>:
> Is there an option that can be passed to avformat_open_input
> (or another call) that will enable decoding of an RTP stream
> carrying H.264 video with the SDP in-band without having to
> pass an out-of-band SDP file?
Isn't there information necessary for decoding H.264 in the sdp file?
Libav-user mailing list
Libav-user at ffmpeg.org
Yes. The important pieces of data are the SPS and PPS.
Reading your question, I realize my subject wasn’t accurate. Here’s the correction.
The streams I’m working with include the SPS and PPS in-band which is normally transmitted via SDP. That’s the actual problem I’m having.
Forgive me if the following is something you already know but I want to make sure I’m explaining my idea correctly and we’re on the same page. I’m hoping there’s an existing solution to my problem.
The streams I’m working with are of the Annex B variety. Annex B provides for the SPS, PPS, and SEI to be sent in-band. They have their own NAL Unit codes. So it’s possible for those packets to be auto-detected pre-decoding. The older version of the software I’m building, a version that sadly isn’t using FFMPEG to parse the containers, is doing precisely that. It waits for the SPS and PPS before submitting anything to the FFMPEG decoder. Most of the streams I’m working with include the SPS and PPS packets just before the first packet of an IDR fragmentation unit so it’s usually less than a second of packets before the SPS and PPS are found.
More information about the Libav-user