[Libav-user] Decoding RTP streams with in-band SDP

[Eric Reichert]

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?
    
    Carl Eugen
    _______________________________________________
    Libav-user mailing list
    Libav-user at ffmpeg.org
    http://ffmpeg.org/mailman/listinfo/libav-user

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.