On 9/16/16, 8:03 AM, "Libav-user on behalf of Carl Eugen Hoyos"
<[email protected] on behalf of [email protected]> wrote:
2016-09-16 2:12 GMT+02:00 Eric Reichert <[email protected]>:
> 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
[email protected]
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
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
