On 9/16/16, 8:03 AM, "Libav-user on behalf of Carl Eugen Hoyos" 
<libav-user-boun...@ffmpeg.org on behalf of ceffm...@gmail.com> wrote:

    2016-09-16 2:12 GMT+02:00 Eric Reichert <ereich...@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@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.

_______________________________________________
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user

Reply via email to